Translate

Сборка Zend Framework в один файл, как способ повышения производительности

В процессе подготовки доклада о производительности для ZFConf 2010, я проверял распространенное мнение, что сборка Zend Framework в один файл существенно повышает скорость работы приложения, которое на нем базируется. "Классическим" трудом на эту тему является вот эта статья - http://dklab.ru/chicken/nablas/49.htmlуважаемого Дмитрия Котерова. Удивительно, но я получил другие результаты, скорость работы моего приложения не только не увеличилась, но и немного замедлилась. Я сам очень удивился, но времени тщательно все проверить у меня не было. На выступлении я рассказал об этой ситуации, многих это удивило и вызвало недовольство, упоминали ту же самую статью Котерова и говорили что так не может быть. Я пообещал перепроверить и выложить результаты на сайте сообщества. Быстро это сделать не получилось, но лучше поздно чем никогда.
Я решил пройти весь процесс заново и посмотреть, что получится во второй раз. 
Еще раз поставлю задачу.
Необходимо сравнить производительность приложения на Zend Framework, когда ZF поставляется в виде библиотеки с набором файлов, и в виде одного большого файла (сборки) в который "слиты" все классы ZF.
Для тестирования используется демо сайт:
  • Сайт содержащий в себе функции среднестатистического, не очень большого сайта типа портала:
  • ZF ~ 160 файлов
  • Приложение ~ 25 файлов
  • Zend_Application, Zend_Loader, Zend_Controller, Zend_View, Zend_Layout, Zend_Filter, Zend_Form, Zend_Db, Zend_Captcha, Zend_Session
Протестировал на двух серверах, первый:
  • Intel(R) Core(TM)2 Duo CPU E7200  @ 2.53GHz
  • 2 GB RAM
  • Linux Debian lenny 8
  • Apache 2.0
  • PHP 5.2.6 mod_php + Suhosin Patch 0.9.6.2
  • Mysql 5.0.51a
  • Zend Framework 1.10.4
второй:
  • Intel(R) Celeron(R) CPU 2.53GHzIntel(R) Celeron(R) CPU 2.53GHz
  • 400 MB RAM
  • Linux Debian lenny 4
  • Apache 2.0
  • PHP 5.2.6 mod_php + Suhosin Patch 0.9.6.2
  • Mysql 5.0.51a
Что замерял:
  • Количество запросов в секунду
    Apache Benchmark
    - ab -c 50 -n 100
  • Время выполнения скрипта (сек)
    - PHP функция microtime
  • Память выделяемая для скрипта (мб)
    - PHP функция memory_get_peak_usage
Для создания сборки я воспользовался сервисом http://isalmin.ru/zfp/. Спасибо создателям, сервис работает довольно качественно. У меня возникла только одна ошибка: Fatal error: Uncaught exception 'Zend_Application_Exception' with message 'Bootstrap class not found'. Я дописал следующую строчку require_once $path; в нужном месте и ошибка исчезла. Сборку я создавал не всего фреймворка, а только тех классов что реально используются в моем приложении. В этом существенное отличие от того что сделал Дмитрий Котеров, как я понял он тестировал на хелло ворлд, в который подключил полностью весь фреймворк. Весь фреймворк весит ~ 5mb, моя же сборка занимает ~ 600kb. Думаю даже очень большой сайт с трудом выйдет за 2-3 мегабайта кода ZF.
Параметры eAccelerator
  • eaccelerator.shm_size=0 (32 Mb)
  • eaccelerator.check_mtime=0
  • eaccelerator.shm_only=1
  • eaccelerator.compress=0
Рекомендую пользоваться веб панелью control.php, которая поставляется вместе с eAccelerator, таким образом можно удобно следить за количеством занятой и свободной памяти, отключаться кешер и оптимайзер, менять параметр check_mtime.
Результаты
Первый сервер, eAccelerator отключен
Server 1 eAccelerator off
файламисборкой
время (cек)память (mb)req/sвремя (cек)память (mb)req/s
0.08352589611.0429840119.610.06340217611.9363174424.08
0.0844872 19.780.070171118 24.2
0.083405018 19.330.069756985 24.06
0.083350897 20.440.069437981 24.22
0.086952925 20.910.069513083 24.31
0.083252907 20.480.069675922 24.51
0.083763123 20.430.069641113 23.66
0.083220959 20.370.070962191 23.83
0.083575964 20.940.069312811 24.09
0.083059072 20.690.06942296 24.66
0.083859396 20.2980.069129634 24.162
      
Время работы php скрипта echo 'hello';   
0.0000069     
Первый сервер, eAccelerator включен:
Server 1 eAccelerator on
файламисборкой
время (cек)память (mb)req/sвремя (cек)память (mb)req/s
0.026121143.3389587455.920.0185899733.72097778366.15
0.025952101 57.80.018706799 68.84
0.026070833 56.780.018576145 66.42
0.026207924 55.290.018529177 67.56
0.025972128 55.190.018697977 68
0.026178122 59.420.018503904 68.32
0.026070118 55.110.018584013 69.49
0.025858879 56.780.018531084 68.66
0.02649498 57.530.018540144 68.14
0.026036978 57.130.018594027 67.95
0.02609632 56.6950.018585324 67.953
Второй сервер, eAccelerator выключен
Server 2 eAccelerator off
файламисборкой
время (cек)память (mb)req/sвремя (cек)память (mb)req/s
0.3297281276.8706169133.60.2022659787.0798149114.58
0.275671005 3.010.194590806 4.66
0.302878141 3.560.20475316 4.69
0.264563084  0.210213184  
0.334601164  0.202888012  
0.304044008  0.202977896  
0.265103817  0.199849844  
0.286854982  0.219155073  
0.279711008  0.19554615  
0.260824919  0.19554615  
0.290398026 3.390.202778625 4.643333
      
      
Время работы php скрипта echo 'hello';   
0.00004     
Второй сервер, eAccelerator включен
Server 2 eAccelerator on
файламисборкой
время (cек)память (mb)req/sвремя (cек)память (mb)req/s
0.1003460881.8997726448.610.0659909252.05498504613.43
0.096465111 9.020.064777851 13.38
0.097507 8.780.064805031 13.19
0.104003906  0.070662975  
0.097606897  0.070662975  
0.116338968  0.06330204  
0.098941803  0.063395023  
0.105087042  0.065068007  
0.098057032  0.064059973  
0.097778082  0.065031052  
0.101213193 8.8033330.065775585 13.33333
Видим что скорость при использовании сборки увеличивается примерно в полтора раза (при этом увеличивается потребление памяти). Что противоречит тому что я получил перед своим докладом. Скорее всего, так произошло потому что сборка, которую я использовал в прошлый раз была избыточной, то есть содержала достаточно много файлов которые не использовались. Но тем не менее цифр о 22 кратном увеличении как у Дмитрия я тоже не получил. Возможно это потому что я не подключал целый фреймворк, а лишь его часть.
Выводы:
  • Сборку ZF в один файл можно рассматривать как способ повышения производительности;
  • Сборка должна содержать по минимуму избыточных файлов, в идеале только те которые нужны для запроса конкретного url;
  • На реальных больших проектах возможны различные подводные камни и профит от увеличения скорости может не стоить того

Комментариев нет:

Отправить комментарий

Постоянные читатели