Symfony 2. Миграция проекта на php 7 с php5.5. Проблемы с производительностью

У меня есть один проект ~4 года назад, я начал с 5.3 и Symfony 2.0, перешел на 5.5 и S2.3. На данный момент я перешел на S2.8 и хочу перейти на php 7.

Поскольку вокруг производительности PHP 7 было так много кучи, мне не терпелось проверить производительность моего проекта в dev env.

Итак, запуск теста в dev env; service находится на бродячем хосте, имеющем как php5-fpm, так и php7.0-fpm, закрытие одного и установка другого.

Я ожидал, что php7 превзойдет php5, но в основном кажется, что php7 в 1,5-2 раза медленнее в моей локальной среде разработки.

Что я делаю не так? Или я должен как-то переписать свое приложение?

phpinfo: php 7 http://pastebin.com/a6a76vE2 php 5 http://pastebin.com/4GBXNmBB

P.S. Да, я понимаю, что запуск тестов в локальной среде разработки не является на 100% достоверным и чистым, но мне нужно только понять, быстрее ли php7, чем php5, как было сказано.

U1

Самое смешное, что blackfire ясно показывает, что php 7 примерно на 45% быстрее, чем php 5. Но когда я осаждаю, я вижу, что производительность ухудшается.

U2

Вот более или менее моя пользовательская конфигурация для dev env. То же самое для php5.5 и php7:

[Date]
date.timezone = Europe/Tallinn

[PHP]
memory_limit = 512M
expose_php = Off
cgi.fix_pathinfo = 0
post_max_size = 10M
upload_max_filesize = 10M
max_execution_time = 60
realpath_cache_size = 4096k
realpath_cache_ttl = 7200

error_reporting = E_ALL | E_STRICT
log_errors = On
error_log = /var/log/php.errors.log

display_errors = On
display_startup_errors = On
html_errors = On

; xdebug
xdebug.remote_enable = On
xdebug.remote_port = 9001
xdebug.max_nesting_level = 200
xdebug.remote_log = /tmp/xdebug.log
xdebug.remote_connect_back = on
xdebug.idekey = "vagrant"

[opcache]
opcache.enable_cli=0
opcache.save_comments=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=66000
opcache.fast_shutdown=1
opcache.enable=1
opcache.revalidate_freq=5
opcache.validate_timestamps=1

person Jevgeni Smirnov    schedule 29.04.2016    source источник
comment
@VaheShadunts, отлично для тебя. Есть подсказки, на что смотреть? Могут быть какие-то настройки opcache, настройки конфигурации приложения или кэширование начальной загрузки?   -  person Jevgeni Smirnov    schedule 29.04.2016
comment
Вы пытались запустить тесты на другой машине или с другой конфигурацией?   -  person A.L    schedule 30.04.2016
comment
@A.L Я думаю, что моя проблема больше связана с конфигурацией, чем с машиной. Но не уверен, что искать. В основном конфигурация php-fpm такая же, конфигурация пула такая же. Код тот же. Так что у меня нет четкого представления.   -  person Jevgeni Smirnov    schedule 30.04.2016
comment
Вы включили opcache в PHP7?   -  person malcolm    schedule 30.04.2016
comment
Евгений, вы делаете обновление композитора после смены версии php? потому что пакеты могут иметь разные версии для версий php5 и php7.   -  person Denis Alimov    schedule 02.05.2016
comment
@DenisAlimov, почистил кэш и все переустановил. похоже не тот случай.   -  person Jevgeni Smirnov    schedule 02.05.2016
comment
1. Вы уверены, что все модули PHP, которые вы запускаете под 5.5, вы также запускаете под 7.0? 2. Я бы протестировал что угодно без включенного xdebug (для обеих версий)   -  person Grzegorz Krauze    schedule 27.11.2016
comment
Вы должны отключить xdebug перед выполнением любого тестирования производительности.   -  person Tomáš Fejfar    schedule 24.01.2017
comment
если вы используете кеш apc, PHP7 переименовал эту библиотеку, и классы Symfony также изменились. Вы должны использовать apcu для всех определений apc.   -  person Ahmet Erkan ÇELİK    schedule 20.02.2017
comment
Vagrant использует возможность совместного использования папок гипервизора. По моему опыту, переход на что-то другое значительно улучшит ваше приложение.   -  person eRIZ    schedule 07.07.2017
comment
@JevgeniSmirnov Проверяли ли вы уведомления и предупреждения в журналах? Когда я обновлял свой проект с PHP 5.X до 7.X, у меня было много уведомлений и предупреждений, которые раньше оставались незамеченными. Они могут быть связаны с вашей проблемой производительности.   -  person diegowc    schedule 19.07.2017


Ответы (2)


Несколько шагов для глобальной оптимизации кода PHP и для PHP7:

  • самообновление композитора
  • обновление композитора
  • композитор dumpautoload -a
  • активировать zend opcache (или любой другой установленный php opcache)
  • in php.ini :
    • opcache.max_accelerated_files=20000 (or more)
    • opcache.validate_timestamps=1
    • opcache.revalidate_freq=10 (или больше)
    • xdebug.default_enable=0
  • перезапустить службу php-fpm7

Если проблемы с производительностью не устранены, профилируйте типичную тестовую страницу с помощью blackfire.

person Takman    schedule 09.07.2017

Причиной этого наверняка будет xdebug. Пожалуйста, выключите его, а затем проверьте производительность.

Я должен отметить, что в нашем случае после перехода с PHP5.5/Symfony 2.0 на PHP7/Symfony 3.0 мы столкнулись с падением производительности. Это было вызвано тем, как Symfony 2.8+ обрабатывает сеансы php. Он хранит их в локальном каталоге вместо стандартного каталога /tmp, который почти всегда хранится в оперативной памяти. Поэтому, если у вас довольно большое количество файлов сеанса, поиск файла с жесткого диска занимает много времени по сравнению с оперативной памятью.

После удаления этого в конфигурации Symfony приложение начало показывать прирост производительности, на который мы надеялись.

person Laurynas Mališauskas    schedule 09.07.2017