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

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

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

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

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

Я сделаю небольшое резюме. Вы не должны оценивать эффективность вашего приложения, основываясь исключительно на переднем контроллере app_dev.php . Этот контроллер создан для использования только для разработки. В разработке вы делаете много изменений в конфигурационных файлах, шаблонах ветвей, активах и т. Д. Symfony проверит сотни файлов для модификаций и перезагрузит много ранее кэшированных материалов, если это необходимо, и, следовательно, большое количество вызовов filemtime , file_exists и 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 

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

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

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

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

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

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

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

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

По-видимому, общие папки Virtualbox довольно медленны, когда дело доходит до чтения / записи файлов: /

Если вы заинтересованы в моем решении,