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

Question

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

Коробка представляет собой Ubuntu 12.04 64-битную машину с Veewee. Это тот же базовый ящик, который мы используем для всех наших веб-проектов, поэтому ничего особенного нет. В моем каталоге сайтов у меня есть канонический каталог (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 

Моя оболочка Provisioner только делает несколько вещей:

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

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

UPDATE

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

• Новая база данных, созданная на той же Бродячей VM как Веб-сервер (локальный)
• новая база данных, созданная на общем сервере Dev используется в исходном вопросе (Dev)
• новая база данных, созданная на экземпляре EC2 (TMP)

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

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

Answer 1

Я просто пытался решить эту проблему самостоятельно. Я попробовал предложения здесь и в Rails Windows Vagrant very slow response time. Никакой реальной удачи, я побрил 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

Answer 2

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

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

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

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

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

Answer 3

У меня тоже подобная проблема. Кажется, что общая папка VirtualBox can be very slow for project tree with +1000 files.

Switching to NFS может быть решением.

Answer 4

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

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

Answer 5

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

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

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

Answer 6

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

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

Up барана (по крайней мере, в Бродячей V2 с VirtualBox) как так

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

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

Answer 7

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

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

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

Answer 8

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

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

Answer 9

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

1. Не использовать синхронизированную папку на всех.

   config.vm.synced_folder "../data", "/vagrant", disabled: true 
   

2. Setub samba server в гостевой VM + сетевой диск на хосте Windows. Есть много статей, как это сделать, например: https://www.liberiangeek.net/2014/07/ubuntu-tips-create-samba-file-server-ubuntu-14-04/

Answer 10

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

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