Приложение Symfony2 очень медленно в VirtualBox

Question

Я запускаю виртуальную копию Debian в VirtualBox для разработки PHP-приложения большего размера в стеке nginx / php5-fpm / MySQL.Разработка происходит в основной ОС (Windows 7 x64), код монтируется как общая папка в гостевой ОС.

Производительность очень низкая.Ниже приведены выходные данные webgrind для собственной файловой системы vbox и монтирования samba с cifs:

В любом случае filemtime, file_exists и is_readable takeнесколько секунд, чтобы бежать.Загрузка процессора очень высокая, использование памяти кажется нормальным.

Разве выходные данные всех этих трех функций не кэшируются в кэше статистики?Почему они так долго?

Я бы очень признателен за любую помощь, которую я могу получить!

Редактировать: Чтобы уточнить, производительность производства в порядке.На нашем (надлежащем, не виртуальном) промежуточном сервере PHP-код выполняется в макс. ~ 60 мс в рабочих настройках и где-то между 100-200 мс в режиме разработки.

Мне нужна помощь, чтобы выяснить, почему VirtualBox в 100 раз медленнее в devРежим & Prod.

Я только что проверил, производственные настройки дают ~ 5секундное выполнение.Все еще непригоден для использования, к тому же с ним неудобно развиваться.

Answer 1

Использовать файлообменник NFS. Samba и общий доступ к файлам vbox могут быть очень медленными.

Ваше профилирование указывает, что операции файловой системы являются узким местом.

Прочитайте эту запись в блоге http://clock.co.uk/tech-blogs/virtualbox-404-shared-folder-update для более глубокого понимания

Answer 2

Я недавно ответил на аналогичный вопрос.Вы можете найти мой предыдущий ответ здесь .

Я сделаю небольшое резюме этого.Вам не следует измерять производительность вашего приложения исключительно на основе фронтального контроллера app_dev.php.Этот контроллер был создан для использования только для разработки.В процессе разработки вы вносите множество изменений в конфигурационные файлы, шаблоны веток, ресурсы и т. Д. Symfony проверит сотни файлов на наличие модификаций и при необходимости перезагрузит множество ранее кэшированных файлов, что приведет к большому количеству вызовов filemtime, * 1007.* и is_readable.Все эти вызовы игнорируются в производственном режиме, потому что Symfony ожидает, что все в кэше будет обновлено.Таким образом, почти все возможное кэшируется в рабочем режиме и используется прямо сейчас без проверки Symfony, был ли файл изменен или нет.Это дает огромный прирост производительности, поскольку перезагрузка отдельных файлов в процессе разработки может занять много раз, чтобы проанализировать его, проверить зависимости от него, восстановить все в зависимости от этих файлов и т. Д.

Если вы проводите сравнительный анализ своихприложение, отметьте его, как если бы он был в рабочем режиме.По крайней мере, если вы не можете настроить все аппаратное обеспечение так, как ожидаете его в производственной среде, выполните следующие шаги.Очистите кэш для производственного режима и используйте app.php вместо app_dev.php.Кроме того, проверьте раздел производительность , который можно найти на symfony.com в документации.Здесь консоль призывает очистить и прогреть кеш в производственной среде.Я думаю, что cache:clear также согреет кеш, но так как я не уверен на 100%, я предпочитаю делать оба вызова:

php app/console cache:clear --env=prod --no-debug
php app/console cache:warmup --env=prod --no-debug

Надеюсь, это поможет.

С уважением, Мэтт

Answer 3

Просто чтобы связать это:

В конце я настроил общий ресурс samba на гостевой ОС, связал его со вторым сетевым адаптером ( только для хоста, как в этом руководстве ) и подключил его как сетевой диск на хосте. OS.

Немного хакерский, но время выполнения сократилось до 100-500 мс с 5-13 с в режиме разработки с профилированием.

Answer 4

Возникла та же проблема, исправлена ​​путем установки cron rsync, который синхронизирует код на ВМ и хосте.

Очевидно, что общие папки Virtualbox работают довольно медленно, когда дело доходит до чтения / записи файлов: /

Подробно о моем решении, если вы заинтересованы

Answer 5

В дополнение к сказанному Matt я рекомендую вам скомпилировать расширение ветки и использовать его в качестве модуля php.Это будет генерировать шаблоны быстрее.Но все же самое важное - это делать любые тесты, запускающие ваше приложение в среде prod, но не в dev или test.Убедитесь, что вы не загружаете модуль xdebug в производство, потому что он также замедлит ваши тесты.

Я не знаю ваших точных настроек, но, скорее всего, вы получите лучшие результаты, если правильно установитеобратный прокси (он же Varnish) вместо AppCache, чтобы сделать как можно меньше запросов на само приложение.