Янв 032014
 

Отключение PHP функции MAIL, спасение от span БотНета

Если Ваш сайт взломали каким то способом, и добрались до PHP функции Mail, ждите санкций и занесение IP Вашего сервера в черный список Спамеров.

Поэтому Возникла необходимость полностью отключить на сервере php функцию mail.

Находим конфигурационный файл: php.ini

Находим в нем директиву disable_functions
Дописываем mail

У Нас получается подобная строчка, возможно в disable_functions уже будут вписано, что то. Допишите Маил в конец строки, Пример:
disable_functions = mail

Перегружаем Веб-Сервер, и радуемся тому, что Ваш сервер больше не спамит.

 Posted by at 03:16
Дек 272011
 

Чтение файла file() быстрее, чем fopen+цикл — ускорение 40%

Для того, чтобы прочитать в массив $x файл размером 1Мб (100 000 строк по 10 байт) можно воспользоваться двумя вариантами: чтение файла с помощью file(), либо традиционным методом fopen/fgets. Разумеется, для файлов разного объема и содержимого скорость может меняться. Но в данном примере статистика такова:file("1Mb_file.txt") работает на 40% быстрее, чем:

 

 

   $f=fopen("1Mb_file.txt","r") or die(1);
   while($x[]=fgets($f,1000));
   fclose($f);

Аналогичные варианты

 

 

   $f=fopen("1Mb_file.txt","r") or die(1);
   while($s=fgets($f,1000)) $x[]=$s;
   fclose($f);

или

 

   $f=fopen("1Mb_file.txt","r") or die(1);
   while(!feof($f))) $x[]=fgets($f,1000);
   fclose($f);

работают еще медленнее (во втором случае лишняя функция feof() заметно снижает скорость). Тот же тест, но на 15Мб файле (100 000 строк по 150 байт) показывает разницу в 50%, в пользу file(). Тест проводился так, чтобы исключить фоновый своппинг во время работы из-за предшествующих команд создания/чтения таких больших файлов. Подсчитать тоже самое на очень маленьких файлах в 1-2 Кб не представляется возможным, т.к. операцию чтения нельзя повторять в течении одного теста, операции чтения будут кешироваться…

 Posted by at 10:43
Дек 272011
 

Циклы: for, foreach, while, count/sizeof() — ускорение 15%-30%

В начале программы создается массив $test из целых чисел (100 000 элементов). Потом один раз запускаются приведенные ниже примеры. Цикл проходит данный массив 3-мя способами (разными циклами) и выполняет кое-какие операции. Не выполнять в цикле ничего нельзя, ибо это будет уже совсем не реальный тест.

  1. {$x=0; foreach($test as $n)                          { $x=sprintf("test%08i",$i);        }}
  2. {$x=0; for ($it=0; $it<100000; $it++)                { $x=sprintf("test%08i",$i);        }}
  3. {$x=0; $it=0; while($it<100000)                      { $x=sprintf("test%08i",$i); $it++; }}
  4. {$x=0; for ($it=0; $it<count($test); $it++)          { $x=sprintf("test%08i",$i);        }}
  5. {$x=0; $it=0; while($it<count($test))                { $x=sprintf("test%08i",$i); $it++; }}
  6. {$x=0; $co=count($test); for ($it=0; $it<$co; $it++) { $x=sprintf("test%08i",$i);        }}
  7. {$x=0; $co=count($test); $it=0; while($it<$co)       { $x=sprintf("test%08i",$i); $it++; }}

 

счетчик кол-во
вызовов
общее
вpемя
сpеднее
вpемя
% от min % от max
test N1 1 12.0313 12.0313 154.4% 100.0%
test N2 1 4.7290 4.7290 00.0% 39.3%
test N3 1 4.7712 4.7712 00.9% 39.7%
test N4 1 10.2847 10.2847 117.5% 85.5%
test N5 1 10.3466 10.3466 118.8% 86.0%
test N6 1 9.1271 9.1271 93.0% 75.9%
test N7 1 9.1409 9.1409 93.3% 76.0%

Почему sprintf, а не реальное echoecho использовать нельзя, т.к. от него будет немерянный буфер (OUTPUT в браузер или консоль).

Теперь о деле. Бесспорный вывод — использование foreach сильно тормозит дело, а между for и while большой разницы нет. (На голом тесте for/while/foreach {..}тормоза foreach — 30%). Это не удивительно, т.к. foreach делает копию массива, на что тратиться масса времени (хотя это только слухи).

Вывод с count() не столь очевиден, потому что от разного текста в цикле % тормознутости от самого быстрого варианта резко возрастает… Я взял цикл с небольшой нагрузкой — проход по огромному массиву $test + форматирование функцией sprintf. Как видите, варинты с count() и заменяющей эту функцию перемнной $co различаются на 10% по скорости между собой (не смотрите на варинант с константой в 100000, заранее знать кол-во элементов невозможно).

Вывод о не ассоциативных массивах: 1) foreach существенно замедляет работу 2) использование count() в простых циклах — замедленение 10%. Но на сложных циклах потери от лишних запусков count() будут абсолютно незаметны, так что ситуация не очевидна.

Сравнение count() и sizeof().

Судя по мануалу — это алиасы. Об этом написано на страницах самих функций и дополнительной странице «Appendex => Aliases list». Что же мы видим на массиве в 100000 элементов:

  1. {$x=0; for ($it=0; $it<count($test); $it++)  { $x=sprintf("test%08i",$test[$it]);}}
  2. {$x=0; for ($it=0; $it<sizeof($test); $it++) { $x=sprintf("test%08i",$test[$it]);}}

 

счетчик кол-во
вызовов
общее
вpемя
сpеднее
вpемя
% от min % от max
test N1 1 3.0087 3.0087 15.7% 100.0%
test N2 1 2.5998 2.5998 00.0% 86.4%

Пусть тесты будут иметь погрешности… Но результат один — count() заметно отстает по скорости от sizeof()! Хм, я бы к записи в мануале сделал приписку: «The sizeof() function is an alias for count(), but последний сильно тормозит!»

Если кол-во элементов в массиве меньше 65000 (64К), то эти функции по скорости практически не различимы. Тут вывод простой — переходим на использованиеsizeof(), как ускоренного алиаса count(). Это принесет свои результаты на огромных массивах.

Ассоциативные массивы: тестирование разных способов перебора

С ними наблюдается таже проблема: на разных по величине массивах разные функции эффективны, но лучше всех foreach!

Массив в 200 элементов и 1000 повторов программы:

  1. {$x=0; foreach($test as $k=>$v) { $x=sprintf("%s=>%s\n",$k,$v);                                                           }}
  2. {$x=0; reset($test); while (list($k, $v) = each($test)) { $x=sprintf("%s=>%s\n",$k,$v);                                   }}
  3. {$x=0; $k=array_keys($test); $co=sizeof($k); for ($it=0; $it<$co; $it++) { $x=sprintf("%s=>%s\n",$k[$it],$test[$k[$it]]); }}
  4. {$x=0; reset($test); while ($k=key($test)) { $x=sprintf("%s=>%s\n",$k,current($test)); next($test);                       }}

 

счетчик кол-во
вызовов
общее
вpемя
сpеднее
вpемя
% от min % от max
test N1 1 8.1222 8.1222 00.0% 78.7%
test N2 1 10.3221 10.3221 27.1% 100.0%
test N3 1 9.7921 9.7921 20.6% 94.9%
test N4 1 8.9711 8.9711 10.5% 86.9%

Тоже самое, но массив в 5000 элементов и 200 повторов:

 

 

счетчик кол-во
вызовов
общее
вpемя
сpеднее
вpемя
% от min % от max
test N1 1 14.4473 14.4473 00.0% 67.2%
test N2 1 18.6801 18.6801 29.3% 86.9%
test N3 1 21.5056 21.5056 48.9% 100.0%
test N4 1 15.8514 15.8514 09.7% 73.7%

Опять тоже самое, но массив в 100 000 элементов и без повторов:

 

 

счетчик кол-во
вызовов
общее
вpемя
сpеднее
вpемя
% от min % от max
test N1 1 3.5116 3.5116 00.0% 82.8%
test N2 1 3.9724 3.9724 13.1% 93.6%
test N3 1 4.2436 4.2436 20.8% 100.0%
test N4 1 4.0026 4.0026 14.0% 94.3%

Другие тесты на холостых циклах тоже показывают преимущество foreach.

Резюме:

  • sizeof() лучше, чем count()
  • в циклах sizeof лучше вообще заменить на переменную
  • for и while практически не отличимы
  • для перебора простых индексных массивов нужно использовать for или while
  • для перебора ассоциативных массивов нужно использотьва foreach
 Posted by at 10:43
Дек 272011
 

Регулярные выражения: PHP(POSIX) vs Perl.

PHP поддерживает регулярные выражения стандарта POSIX/eger*/ и PERL/preg*/-ориентированные (об их различии тут — php.spb.ru/regular_expression.html). Кто из них работает быстрее?

Хочу заранее предупредить любителей Перла, чтобы не радовались: хоть перловые реги и круче пхпышных, только ничто и никто не мешает использовать в PHP перловые реги! Наверно, потому их и встроили в PHP, что уж больно тормоза большие… 🙂

Итак, простейший текст. Поиск простого выражения в тексте, который состоит из многократного повторения данной статьи (получается размер переменной $text в 3 Мб).

Тест вызывает всего 1 раз, ибо реги имеют встроенное средство для кеширования результатов компиляции. Т.е. перед запуском проиходит компиляции, а повторные реги не компилируются. Это особенности регулярных выражений. Разные языки программирования в состоянии хранить разное число откомпилированных выражений, что вызывались (в порядке вызова в программе). И в данном тесте как раз нет эффекта от компиляции, т.к. функция вызывается всего один раз.

  1. {eregi("МаС+иВ",$text);}
  2. {preg_match("/МаС+иВ/im",$text);}

 

счетчик кол-во
вызовов
общее
вpемя
сpеднее
вpемя
% от min % от max
test N1 1 1.3339 1.3339 107.8% 100.0%
test N2 1 0.6417 0.6417 00.0% 48.1%

 

  1. {eregi("(ма[a-zа-я]{1,20})",$text);}
  2. {preg_match("/(ма[a-zа-я]{1,20})/im",$text);}

 

счетчик кол-во
вызовов
общее
вpемя
сpеднее
вpемя
% от min % от max
test N1 1 0.4521 0.4521 76.9% 100.0%
test N2 1 0.2556 0.2556 00.0% 56.5%

Пример для другого выражения и 30-мегабайтного текста (все те же повторы статьи, что вы сейчас читаете):

  1. {eregi("(ма[a-zа-я]{1,20})",$text);}
  2. {preg_match("/(ма[a-zа-я]{1,20})/im",$text);}

 

счетчик кол-во
вызовов
общее
вpемя
сpеднее
вpемя
% от min % от max
test N1 1 1.3430 1.3430 60.6% 100.0%
test N2 1 0.8365 0.8365 00.0% 62.3%

Я еще писал штук пять разных выражений, но тенденция не меняется. Скорость может меняться, но Pelr обгоняет POSIX минимум на половину. Этого достаточно, чтобы похоронить функции регулярных выражений от PHP (POSIX). Для всех функций есть аналогичные Perl-ориентированные (все они встроены в PHP).

Далее один очень показательный пример на этой же статье (увеличение до 28Мб). Пример ищет в тексте e-mail. По свойству «жадности» регулярных выражений будет найден самый большой и наболее близкий к левому краю адрес.

Этот пример огорчит любителей перла. Приятно их огорчать 🙂

  1. {eregi("([a-z_-]+@([a-z][a-z-]*\.)+([a-z]{2}|com|mil|org|net|gov|edu|arpa|info|biz))",$text);}
  2. {preg_match("/([a-z_-]+@([a-z][a-z-]*\.)+([a-z]{2}|com|mil|org|net|gov|edu|arpa|info|biz))/im",$text);}

 

счетчик кол-во
вызовов
общее
вpемя
сpеднее
вpемя
% от min % от max
test N1 1 11.6828 11.6828 680.3% 100.0%
test N2 1 1.4973 1.4973 00.0% 12.8%

Из одного теста делать вывод сложно, но, видимо, чем сложнее регулярное выражение, тем больше POSIX отстает от Perl.

А теперь тот же пример, но только в статье (увеличение до 28Мб) нет НИ ОДНОГО символа «@» (я специально сделал копию статьи и стер эти символы):

  1. {eregi("([a-z_-]+@([a-z][a-z-]*\.)+([a-z]{2}|com|mil|org|net|gov|edu|arpa|info|biz))",$text,$ok); echo $ok[1];}
  2. {preg_match("/([a-z_-]+@([a-z][a-z-]*\.)+([a-z]{2}|com|mil|org|net|gov|edu|arpa|info|biz))/im",$text,$ok); echo $ok[1];}

 

счетчик кол-во
вызовов
общее
вpемя
сpеднее
вpемя
% от min % от max
test N1 1 0.5854 0.5854 00.0% 10.2%
test N2 1 5.7671 5.7671 885.2% 100.0%

Что мы видим?.. Ничто в этом мире не совершенно. Конечно, это очень не оптимизированное выражение для поиска email’ов, но всё же все те, кто кричал мне в форуме «ereg — отстой», на этом и похожих примерах могут отдыхать. Бывает же, что в тексте нет ни одной собачки 🙂

Итак, вывод о скорости с примерами был дан выше. Вывод однозначный — надо использовать Perl-ориентированные регулярные выражения. В начеле главы я упоминал о кешировании откомпилированных копий регов. Если в программе одно и тоже выражение встречается неоднократно, производительность может отличаться не просто многократно, а в 10-100-1000 раз!

Селдующий пример вызывается 200 раз подряд над текстом в 250Кб:

  1. {eregi("МаС+иВ",$text);}
  2. {preg_match("/МаС+иВ/im",$text);}

 

счетчик кол-во
вызовов
общее
вpемя
сpеднее
вpемя
% от min % от max
test N1 1 17.6384 17.6384 72381.4% 100.0%
test N2 1 0.0243 0.0243 00.0% 00.1%

Что такое кеш — знают все. Видимо именно с кешем в PHP проблеммы… Кстати, ради примера, отключите в BIOSе вашего комптьютера кеш процессора и попробуйте загрузить Windows 2000… Не дождетесь! (Кажется, их называют L1 и L2 — два разных кеша для кода и данных первого и второго уровня, какой то из них можно отключить.)

 Posted by at 10:39
Дек 272011
 

Выносите многомерные массивы из «текстовых строк» — ускорение 25-30%. Одномерные можно не выносить.

При использовании многомерных массивов в строках наблюдается заметное снижение скорости Из-за многомерности нужно заключать переменные в парные фигурные скобки.

  1. {$x="test ".$myarray["name"]["second"][1]." test";       }
  2. {$x="test {$myarray[name][second][1]} test";             }
  3. {$x="test ";$x.=$myarray["name"]["second"][1];$x=" test";}

 

счетчик кол-во
вызовов
общее
вpемя
сpеднее
вpемя
% от min % от max
test N1 1 3.5369 3.5369 00.0% 69.9%
test N2 1 5.0605 5.0605 43.1% 100.0%
test N3 1 4.6017 4.6017 30.1% 90.9%

Тот же пример с ассоциативным 3-х мерным массивом, но с обращением к элементу по его индексному номеру:

  1. {$x="test ".$myarray[3][2][0]." test";       }
  2. {$x="test {$myarray[3][2][0]} test";         }
  3. {$x="test ";$x.=$myarray[3][2][0];$x=" test";}

 

счетчик кол-во
вызовов
общее
вpемя
сpеднее
вpемя
% от min % от max
test N1 1 3.3012 3.3012 00.0% 73.1%
test N2 1 4.1667 4.1667 26.2% 92.3%
test N3 1 4.5145 4.5145 36.8% 100.0%

Разница в 1 и 2 вариантах очень мала. Это говорит, что потери на не эффективное использование кавычек не слишком большое, чем доступ к массивам (см. тесты в первой главе).

  1. {$x="test".$myarray["test"]."test";}
  2. {$x="test$myarray[test]test";      }
  3. {$x="test{$myarray[test]}test";    }

 

счетчик кол-во
вызовов
общее
вpемя
сpеднее
вpемя
% от min % от max
test N1 1 2.8495 2.8495 00.0% 80.9%
test N2 1 2.9519 2.9519 03.6% 83.9%
test N3 1 3.5202 3.5202 23.5% 100.0%

А теперь, на основании всех трех тестов, однозначный вывод: использовать фигурные скобки для обозначения границ имени элемента многомерного массива НЕЛЬЗЯ. Это сильно снижает скорость работы — 25-30% (в третьем варианте от простого добавления скобок скорость понизилась на четверть). Не использовать скобки нельзя. Следовательно, единственный способ не терять 30% скорости — выносить многомерные массивы из скобок.

Такой же тест, но для одномерных:

  1. {$x="test".$myarray["test"]."test".$myarray["test"]."test".$myarray["test"];   }
  2. {$x="test$myarray[test]testtest$myarray[test]testtest$myarray[test]test";      }
  3. {$x="test{$myarray[test]}testtest{$myarray[test]}testtest{$myarray[test]}test";}

 

счетчик кол-во
вызовов
общее
вpемя
сpеднее
вpемя
% от min % от max
test N1 1 6.5843 6.5843 00.0% 78.0%
test N2 1 6.7770 6.7770 02.9% 80.3%
test N3 1 8.4406 8.4406 28.2% 100.0%

Сравнивая два последних теста очевидно, что одномерные массивы можно и не выносить, потери всего 3-4% ( а вот на простых переменных — потери 25-40%!).

 Posted by at 10:38