Drupal очень медленный в среде бродяг

Я начал переносить многие наши среды разработки в Vagrant. До сих пор это было отлично для почти всего, но наша первая миграция Drupal непригодна для использования. Это невероятно медленно. Наши сайты Wordpress, CakePHP и Node.js все работают очень адекватно или лучше, но не Drupal. Это просто ужасно.

Коробка - созданная Veewee Ubuntu 12.04 64-разрядная машина. Это тот же базовый ящик, который мы используем для всех наших веб-проектов, поэтому ничего особенного нет. В моем каталоге сайтов у меня есть канонический каталог (sites/my-site/) со всеми ресурсами сайта и символическая ссылка на этот канонический каталог с именем домена (sites/dev.mysite.com -> /vagrant/www/sites/my-site), который, очевидно, требуется для некоторого модуля, который использует команда.

Это смешанная команда разработчиков Windows/OSX, и она замедляется на обеих платформах. Единственный полу-нетрадиционный отрывок из моего Vagrantfile таков:

config.vm.forward_port 80, 8080

config.vm.share_folder( "v-root", "/vagrant", ".", :extra => 'dmode=777,fmode=777' )

# Allows symlinks to the host directory.
config.vm.customize ["setextradata", :id, "VBoxInternal2/SharedFoldersEnableSymlinksCreate/v-root", "1"]

Vagrant::Config.run do |config|
  config.vm.provision :shell, :path => "provision.vm.sh"
end

Мой помощник оболочки выполняет только пару действий:

Устанавливает drush
Создает вышеупомянутую символическую ссылку в каталог канонического сайта
Записывает серверный блок Nginx
При необходимости создается файл settings.php.

Есть ли что-нибудь, что я могу сделать для повышения производительности? Как, много?

UPDATE

Я сузил это до такой степени, что проблема заключается в удаленной базе данных. Чтобы сравнить яблоки с яблоками без багажа проекта, я загрузил новую копию Drupal 7.21 и выполнил стандартную установку с веб-сервера Vagrant против 3 различных баз данных:

Новая база данных, созданная на той же Vagrant VM, что и веб-сервер (localhost)
Новая база данных, созданная на общем сервере dev, используемая в исходном вопросе (dev)
Новая база данных, созданная на экземпляре EC2 (tmp)

Как только это было сделано, я вошел в систему с новым Drupal и загрузил домашнюю страницу (localhost: 8080) 5 раз. Затем я подключался к каждой базе данных и загружал одну и ту же страницу таким же образом. Я обнаружил, что страница загружалась на 4-6 раз медленнее, когда Drupal был подключен к удаленной базе данных.

Помните, что это новая (стандартная) установка. Нет проектного багажа.

Ответ 1

Я просто пытался решить эту проблему сам. Я попробовал предложения здесь и в Rails Windows Vagrant очень медленное время отклика. Никакой реальной удачи, я побрил 200 мс от времени ответа 1800 мс на теплый запрос без реальных данных. Это с Ruby on Rails, а не с Drupal. Проблема одна и та же.

Переключение общей папки в Rsync дало мне время отклика ~ 280 мс на тот же запрос.

Vagrantfile:

  config.vm.synced_folder '.', '/vagrant', type: 'rsync',
                                       rsync__exclude: '.git/'

Использование:

$ vagrant up
$ vagrant rsync-auto

Последняя команда будет следить за тем, чтобы ваш рабочий каталог и синхронизация были изменены автоматически.

См. https://www.vagrantup.com/docs/synced-folders/rsync.html и https://www.vagrantup.com/docs/cli/rsync-auto.html

Ответ 2

Меня тоже поражает аналогичная проблема. Кажется, что общая папка VirtualBox может быть очень медленной для дерева проектов с +1000 файлами.

Переключение на NFS может быть решением.

Ответ 3

Проблема почти наверняка будет либо skip_name_resolve (требуется в my.cnf), либо VirtualBox плохо справляется с общими каталогами с большим количеством файлов. Оба легко отслеживаются с помощью strace -c, но вам может быть проще просто исправить их по одному и посмотреть, какой из них исправляет проблемы с производительностью.

Если вы все еще видите медленность после обоих этих изменений, дайте мне знать, и мы можем отладить его дальше.

Ответ 4

Я получил здесь через Google для подобных, поэтому я отвечаю в надежде, что другие находят это полезным.

Если вы используете точную коробку бродяг в качестве отправной точки, стоит отметить, что поле по умолчанию имеет только 360 МБ ОЗУ.

Поместите плунжер (по крайней мере, в Vagrant V2 с VirtualBox) так

config.vm.provider :virtualbox do |vb|
    vb.customize ["modifyvm", :id, "--memory", "1024"]
end

Это сделало Drupal гораздо более отзывчивым для меня.

Ответ 5

Это просто приложение PHP/MySQL, поэтому нет особого значения в Drupal, кроме того, как он был настроен. Возможно, вы сделали кое-что из этого, но вот некоторые предложения по изоляции проблемы.

Проверьте dblog Drupal на наличие ошибок.
Проверьте свои журналы nginx и php на наличие ошибок.
Посмотрите, сколько активных модулей вы используете (более 100? Это будет очень тяжелая установка).
Установите новый экземпляр Drupal и сравните его. Это может изолировать проблему к вашему экземпляру, а не к Drupal вообще.

Если вы обнаружите, что это ваш экземпляр Drupal

Установите модуль devel и включите отчет по памяти, чтобы вы знали, сколько памяти используется для загрузки страницы, а также для улучшения базовой линии.
Удостоверьтесь, что у вас установлен APC или другой PHP-код, и убедитесь, что коэффициент успеха хорош. Если вы не запускали его раньше, обратите внимание на разницу в использовании памяти, сообщаемую devel.
запустите что-то вроде xhprof или отключите подозрительные модули, пока не найдете основных преступников.
включить mysql slow и индексный журнал для поиска потенциальных проблем, затем добавить индексы или выполнить другие действия соответствующим образом

Если ваши другие приложения работают нормально, я подозреваю, что есть проблема с конкретным модулем или у вас есть полная установка Drupal, которая требует некоторой оптимизации или большей памяти.

Ответ 6

Я пробовал почти все, чтобы заставить моего медленного Vagrant ускориться и, наконец, наткнулся на это в трекере проблем проекта.

config.vm.provider "virtualbox" do |v|
    v.memory = 1024
    v.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
    v.customize ["modifyvm", :id, "--natdnsproxy1", "on"]
end

Я ранее пробовал NFS безрезультатно; это была серебряная пуля.

Ответ 7

Так как Vagrant 1.5 вы можете использовать rsync как механизм для синхронизации папки с гостевой машиной. Поскольку rsync копирует файлы непосредственно в удаленную файловую систему, производительность заметно лучше, чем NFS и общие папки VM.

Подробнее об этом можно прочитать здесь: http://www.vagrantup.com/blog/feature-preview-vagrant-1-5-rsync.html.

Ответ 8

Задержка - большая проблема с подключением к базе данных в любой серверной среде. Даже простое шифрование в соединениях с БД будет существенной проблемой производительности, хотя, по-видимому, это необходимо в этих условиях.

Какое время вашего пинга в базе данных? Если у вас есть хотя бы одна поездка туда и обратно для каждого запрошенного вами запроса, то это будет складываться. Плюс немного времени для шифрования. Еще хуже. если вы не используете постоянные соединения с базой данных.

Я бы подумал о том, где вы делаете свое кеширование. Например, кеш в memcached на VM, а не в БД.

Ответ 9

Я сталкиваюсь с той же проблемой. Эти рекомендации будут особенно полезны для тех, кто использует хост-компьютер Windows. Вы не сможете получить достойную производительность без поддержки NFS (для окон это большая проблема), поэтому:

Не используйте синхронизированную папку вообще.
```
config.vm.synced_folder "../data", "/vagrant", disabled: true
```
Сервер Setub samba в гостевом VM + сетевом диске на хосте Windows. Есть много статей, как это сделать, например: https://www.liberiangeek.net/2014/07/ubuntu-tips-create-samba-file-server-ubuntu-14-04/

Ответ 10

Если доля NFS с Vagrant все еще слишком медленная для вас, вы можете сделать обратное:

Вместо установки сервера NFS на хост-машине вы можете установить его на гостевой машине VM: http://guillaumeduveau.com/en/drupal-lightning-fast-synced-folders-in-vagrant-virtualbox/