Comments 21
А opcache включен?
Вообще не понимаю причем здесь Vagrant…
Какой огромный костыль. Логи так вообще можно в Mongodb вывести.
Мне отдельно кэш и логи перенести в vm, помогло не значительно. Но когда я полностью перенес проект в файловую систему виртульной машины. Все работать стало даже быстрее чем на хосте.
Еще неплохо помогало использование nfs, но в данном случае это было невозможно.
Еще неплохо помогало использование nfs, но в данном случае это было невозможно.
Простите, а вы шарили исходники виртуалке вагранта по какому протоколу: smb?
Это дефолтный безопасный, но очень уж медленный протокол.
Если в качестве хост системы *nix, то намного лучше использовать nfs.
Это дефолтный безопасный, но очень уж медленный протокол.
Если в качестве хост системы *nix, то намного лучше использовать nfs.
Заработать nfs в Vagrant в OpenSUSE 13.1 у меня так и не удалось. Пришлось для разработки хранить кеш и логи в /tmp =(
А в Вашей системе присутствует nfs сервер, ибо у меня были проблемы с этим?
Также vagrant up может потребовать ввода пароля суперпользователя (для редактирования /etc/exports) — такое у меня на osX
Также vagrant up может потребовать ввода пароля суперпользователя (для редактирования /etc/exports) — такое у меня на osX
NFS поставил, с супер правами последний vagrant — тоже стал нормально запрашивать — раньше падал. На сколько смог выяснить, проблема с init скриптами в самой OpenSUSE. Т.е. в обычном случае vagrant при старте машин, где требуется монтировать директории по nfs, чтобы определить статус nfs сервера, обращается как-то так: #service nfs-server status, а в сьюзе эта команда выводит подсказку, о том, что нужно делать тоже, но через systemctl…
Сейчас сходу нет под рукой SUSE, но происходит что-то типа того. Нужно подробнее посмотреть и сообщить о баге разработчикам vagrant-а. А пока, малой кровью, просто перекинул кеш директории и логи в /tmp/
Сейчас сходу нет под рукой SUSE, но происходит что-то типа того. Нужно подробнее посмотреть и сообщить о баге разработчикам vagrant-а. А пока, малой кровью, просто перекинул кеш директории и логи в /tmp/
Думаю стоит обратить внимание на подводный камень что тот же самый Kernel уйдет в другие окружения (e.g staging, production). Т.е. или изменение делается строго у себя и не комитится, или надо вставить проверку откружений, что еще более загрязняет код чисто по причине недееспособности Vagrant. Ну или дождаться версии 1.5, где возможность автоматической синхронизации с помощью rsync идет из коробки.
Проблема не только в кеше и логах. Проблема в механизме синхронизации.
Все довольно решаемо, как раз не так давно описывал у себя в блоге: akuma.su/blog/uskoryaem-symfony2-na-vagrant.html
Решается заменой механизма синхронизации на SMB/NFS.
Не сочтите за рекламу. Сейчас у меня тяжелые страницы Symfony2 из Vagrant'а грузятся за 2-3 секунды.
Все довольно решаемо, как раз не так давно описывал у себя в блоге: akuma.su/blog/uskoryaem-symfony2-na-vagrant.html
Решается заменой механизма синхронизации на SMB/NFS.
Не сочтите за рекламу. Сейчас у меня тяжелые страницы Symfony2 из Vagrant'а грузятся за 2-3 секунды.
Если вы вынесите директории с кэшем/логами/вендорами на нативную файловую систему или замените nfs/smb на rsync то получите значительно большой прирост производительности. Именно об этом статья.
Да, все верно. Только с rsync очень неудобно работать. Он действует только в одну сторону, поэтому лучше уж smb/nfs.
Я для CI настроил rsync + nfs для артефактов. Такие вещи как установка вендоров и прочее происходят теперь чуть быстрее. Хотя если честно время самого билда не сильно улучшилось.
Ну, при работе с той же симфонией это неудобно будет.
Хочу я, допустим, сгенерировать класс сущности. rsync его не убьет(--delete), нужно запускать rsync-back (например).
Настроить nfs на отдельные директории жутко неудобно, это же под каждый бандл нужно настраивать. В общем, меня такой вариант не особо устроит.
В issue гитхаба уже долго висит предложение сделать двусторонюю синхронизацию с помощью аналога rsync, не помню как называется. Все очень ждут этой фичи.
Хочу я, допустим, сгенерировать класс сущности. rsync его не убьет(--delete), нужно запускать rsync-back (например).
Настроить nfs на отдельные директории жутко неудобно, это же под каждый бандл нужно настраивать. В общем, меня такой вариант не особо устроит.
В issue гитхаба уже долго висит предложение сделать двусторонюю синхронизацию с помощью аналога rsync, не помню как называется. Все очень ждут этой фичи.
Для разработки rsync не поможет, это да. С той же symfony под тот же phpstorm у нас должен быть доступ к вендорам и кешу. Хотя можно ускорить работу приложения просто вынеся тот же кеш во внутреннюю файловую систему. Но тогда придется отказаться от автокомплита для сервисов и т.д.
Да, были попытки даже прикрутить unison, но как по мне так это того не стоит. Лучше купить SSD и не париться. А там где производительность критична (например CI) можно и rsync использовать.
Да, были попытки даже прикрутить unison, но как по мне так это того не стоит. Лучше купить SSD и не париться. А там где производительность критична (например CI) можно и rsync использовать.
Sign up to leave a comment.
Как я Symfony2 c Vagrant подружил