Я собрал сайт D7 с подтемой Minelli. По пути я много экспериментировал с разными темами, разными модулями. В какой-то момент у меня возникла странная проблема с производительностью, и теперь я не знаю, что вызвало ее тема / модуль / конфигурация.

Проблема в том, что когда я впервые захожу на сайт, показ первой страницы занимает около 15 секунд. Затем я могу перемещаться по сайту, и он очень отзывчивый. Если я оставлю это на час или около того, а затем вернусь к нему, первый запрос снова будет очень медленным.

Я очистил кэш, так что это не должно быть проблемой. Также у меня отключены темы и модули, которые я не использую. Я переместил сайт на новую инфраструктуру, но проблема последовала за этим!

Куда мне идти дальше?

Есть три вещи, которые я бы проверил.

Во-первых, если вы находитесь на производственном сайте и не редактируете файлы PHP, то вам следует убедиться, что APC включен, имеет достаточно памяти и имеет длинный TTL (вы можете использовать день или никогда не заканчиваться, если хотите). Вы также можете рассмотреть настройку apc.stat=0. Документы APC содержат всю информацию, необходимую для настройки TTL. Для выбора объема памяти, вы должны прикрепить файл apc.php где-нибудь защищенным и следить за использованием памяти и статистикой оттока. Отрегулируйте память APC так, чтобы ваш шанс пропустить очень низок. Начальная медлительность может быть вызвана тем, что APC заполнен и опустошается (IIRC, APC сбрасывает весь кэш при заполнении вместо использования LRU или более продвинутых стратегий кэширования).

Во-вторых, убедитесь, что MySQL настроен правильно. Вы можете использовать mysqltuner для настройки размера буфера. Ваша первоначальная медлительность может быть связана с загрузкой таблиц с диска и / или отсутствием кэша запросов. Хотя mysqltuner и не идеален, он направляет вас в правильном направлении.

В-третьих, убедитесь, что у вас есть настоящая стратегия Cron Drupal . Лично я бы отключил автоматические cron в "admin / config / system / cron" и настроил запуск crontab каждую ночь. Вы также можете попробовать Elysia Cron, если вам действительно нужен более тонкий контроль над вещами. Таким образом, вы можете запускать необходимые задачи так часто, как вам нужно, но обычные задачи выполняются в одночасье. Ваша первоначальная медлительность может быть связана с тем, что cron запускается каждый час. Вы можете убедиться в этом, посмотрев, когда cron запускает «admin / reports / dblog», и попытаться сопоставить его с вашей медлительностью.

Ivanhoe123, вероятно, прав: Drupal 7 поставляется с включенным по умолчанию «бедным человеком». Короче говоря, это означает, что (время от времени) cron запускается до того, как Drupal рендерит страницу, задерживая все.

Всегда старайтесь использовать настоящую работу cron на производственных площадках. Для получения более подробной технической информации см. Http://drupal.org/cron или обратитесь в свою хостинговую компанию.

Чтобы отключить его, перейдите в admin / config / system / cron и выберите «Никогда».

Модуль Devel предлагает ведение журнала базы данных, чтобы проверить, есть ли у вас длительные запросы.

Если это не поможет, возьмите XHProf или XDebug и найдите виновный код. XHProf (профилировщик) рисует вам красивую карту всех функций, которые выполняются на сервере, и сообщает, какие из них занимают больше всего времени выполнения. С другой стороны, когда XDebug (отладчик) настроен с IDE, такой как Eclipse ( см. Видео ), он позволяет вам детально изучить каждую функцию, выполняемую в реальном времени. Профилировщик даст вам представление о том , что выполняется; в то время как отладчик покажет вам, почему он выполняется.

Просто из аромата вопроса, я сразу думаю о трех (3) вещах

• MySQL Storage Engine / CPU
• Кэширование базы данных
• Блокировка стола

MySQL Storage Engine

Если вы не используете поиск / индексацию FULLTEXT, я настоятельно рекомендую вам преобразовать все ваши данные MyISAM в InnoDB. MyISAM не предназначен для использования преимуществ нескольких процессоров и нескольких ядер. InnoDB был значительно улучшен для многократного использования ЦП, а также для чтения / записи гиперпоточности.

Вот некоторые сообщения, которые я сделал об этом в StackExchange администратора баз данных и на этом сайте в отношении настройки MySQL для производительности InnoDB

• Sep 20, 2011: Многоядерность и производительность MySQL
• Sep 12, 2011: Можно заставить MySQL использовать более одного ядра
• Jun 07, 2011: Как мне преобразовать базу данных из MyISAM в InnoDB?
• May 26, 2011: О производительности однопоточных и многопоточных баз данных
• Apr 15, 2011: https://drupal.stackexchange.com/questions/1715/what-would-be-the-optimal-mysql-configuration-for-a-drupal-7-site/2367#2367

Кэширование базы данных

Еще один веский аргумент для преобразования всех данных MyISAM в InnoDB - это то, как MySQL кэширует данные / индексы. Механизм хранения MyISAM кэширует только индексы. InnoDB кеширует данные и индексы . В свете этого вы можете выделить достаточно памяти для пула буферов InnoDB для размещения одного из следующих (в зависимости от того, что меньше)

• Все данные и индексы InnoDB (идеально, если у вас достаточно оперативной памяти и для ОС; устраняет последующие задержки)
• 75% установленного ОЗУ (если у вас больше данных / индексов InnoDB, чем ОЗУ; минимизируется задержка)

Если вы используете MySQL 5.1, вы можете установить innodb_max_dirty_pages_pct = 0. Это немного увеличит дисковый ввод-вывод, но буферный пул InnoDB будет очищен достаточно, чтобы старые страницы данных и индексы могли вращаться без скачков дискового ввода-вывода. MySQL 5.5 и плагин InnoDB MySQL 5.1 не нуждаются в этой настройке, так как он имеет лучший механизм очистки пула буферов по умолчанию.

Если об использовании InnoDB не может быть и речи, вам может понадобиться использовать memcached или лак. Это позволяет разработчику определять, как долго кэшированные данные будут находиться в оперативной памяти сервера. Естественно, это потребует усовершенствования в разработке, чтобы сделать ваше приложение осведомленным о memcached / varnish.

Блокировка стола

• InnoDB выполняет блокировку на уровне строк, что позволяет выполнять транзакции и неблокирующие операции чтения .
• MyISAM выполняет полную блокировку таблицы только для каждого INSERT, UPDATE и DELETE .

эпилог

Вы не можете избежать начальной задержки после перезапуска MySQL. Тем не менее, как только вы улучшите MySQL, используя вышеупомянутые предложения / информацию, вы больше не будете испытывать последующих задержек.

Я бы использовал такие инструменты, как YSlow, Firebug и т. Д., Чтобы точно определить, что происходит, когда вы загружаете указанную страницу и сразу после нее. Проверьте, не является ли это проблемой кеширования, и, кроме того, проверьте, как она работает, когда вы заходите на страницу как анонимный пользователь, а затем как аутентифицированный пользователь. Сравните это с вашими настройками производительности в Drupal.

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

Похоже, Крон работает.

Проверьте свои настройки здесь: admin / config / system / cron

Из-за этого я чуть не бросил Drupal для моего последнего проекта.

Там должно быть больше, чем одна причина. Мне еще предстоит найти решение «исправить все», которое срабатывает каждый раз, когда возникает проблема.

Системный журнал и Ubuntu / Debain

Первый раз, когда я столкнулся с прерывистой 15-секундной загрузкой, был во время работы drupal на (выделенных, не общих) системах на основе Debian / Ubuntu. Отключение модуля Syslog было решением для меня.

Как сказал @BetaRide, использование xDebug или другого PHP-профилировщика чрезвычайно полезно.

Все еще проблема - обходной путь

Что касается других моих установок, я все еще в растерянности.

Эта проблема более заметна на моем сервере разработки и при установке Drupal с низким трафиком.

В качестве обходного пути я настроил задание cron для загрузки домашней страницы сайтов каждые 60 секунд, а также скрипт cron Drupal каждые 300 секунд. Это, очевидно, не оптимально, но я бы предпочел, чтобы wget или curl испытывали 15-секундное время загрузки вместо человеческого посетителя.

Многие люди предполагают, что эта проблема может быть связана с блокировкой синхронных фоновых процессов , особенно связанных с тяжелыми заданиями cron .

Если это правда, существует отличная пара модулей, находящихся в стадии активной разработки gielfeldt *, которые могли бы устранить эту проблему или, по крайней мере, могли бы предложить некоторые подсказки и помочь разработчикам сайтов диагностировать и лечить конкретных преступников в их случаях. Оба заменяют блокирующие синхронные процессы неблокирующими асинхронными HTTP или командами, и оба предлагают соответствующие отчеты, которые могут идентифицировать проблемные процессы:

• Фоновый процесс и связанные с ним модули позволяют асинхронно обрабатывать очередь фоновых процессов Drupal, поэтому они не блокируются. Это может остановить проблему. Кроме того, благодаря встроенному модулю фонового процесса Apache Server, выпущенному в последней версии, появился базовый, но улучшенный отчет по пользовательскому интерфейсу с функциями для отслеживания, разблокирования и проверки времени запуска и хода этих процессов. Это может идентифицировать проблемный процесс.
• Ultimate Cron основывается на фоновом процессе, чтобы задачи, запускаемые cron, имели свои собственные отдельные асинхронные расписания, каждый из которых можно отслеживать и останавливать в пользовательском интерфейсе. Помимо того, что он отлично подходит для отделения тяжелых задач, снижающих производительность, от обычной очистки с минимальными издержками, он также предоставляет вам отчет с удобной информацией, такой как продолжительность выполнения каждой отдельной задачи, запускаемой cron, при последнем запуске, текущее состояние, и т.д. Это также может снять блокировку и / или выявить проблемные процессы.

В любом случае оба они очень полезны; для этой проблемы они могут использоваться для проверки (очень правдоподобной) теории, что блокировки вызваны синхронными процессами блокировки или прогонами cron. Потенциально они могли бы решить проблему, выполняя их асинхронно, а не синхронно, и они могли бы также предложить подсказки относительно того, какие конкретные процессы вызывали задержку. (имейте в виду, что их документация находится в стадии разработки ...

Однако, если они вообще не могут быть настроены на помощь, это говорит о том, что проблема не только в синхронных фоновых процессах. FWIW, у меня никогда не было этой конкретной проблемы на сайте с тех пор, как эти модули работали должным образом (пока - дрова), но я видел это на своих сайтах раньше, а также на живых сайтах Drupal в дикой природе.

Также следует помнить о других связанных подключаемых модулях, которые в настоящее время разрабатываются - например, в сложных случаях высокой интенсивности Ultimate Cron Queue Scaler , которая позволяет регулировать пороговые значения, может помочь уменьшить проблемы производительности, связанные с cron.

* нет принадлежности, я просто очень впечатлен пользователем их работы

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

1. вызов, drupal_cron_run()вызванный cron ядра бедняка, добавляет ~ 5 секунд к времени запроса на моей машине разработчика. Это можно проверить, раскомментировав тесты вокруг вызова drupal_cron_run()in modules/system/system.moduleinsystem_run_automated_cron()
2. очистка всех кешей добавляет ~ 2 к времени запроса на моей машине разработчика. Это можно проверить, выполнив drush cc allи перезагрузив страницу снова.

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

Хотя я не уверен насчет кеширования. Я не коснулся настроек кэша по умолчанию для этого сайта. Я думаю, что drupal время от времени перестраивает все кэши, возможно, вызванные cron, но я не уверен, как это сделать. Но задержка в 7 с - это то, что я вижу, когда попадаю на страницу через несколько часов.

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

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

1. На вашем сервере создайте папку или другую учетную запись (это может быть лучше), где вы собираетесь выполнить чистую установку Drupal с той же версией, которую вы используете на своем сайте. Затем, без добавления какого-либо модуля или темы, проверьте время, которое требуется сайту для ответа на первый запрос и следующий запрос. Если все работает хорошо, вы можете игнорировать проблемы конфигурации сервера, если он ведет себя так же, как ваш текущий, у вас есть ошибка конфигурации с вашим веб-сервером или базой данных.

2. Если результаты, полученные на шаге 1, хороши, а сервер отвечает быстро, а последующие запросы выполняются так же быстро, установите на сайт чистой установки только тему с текущего сайта и протестируйте ее снова. Если все по-прежнему быстро реагирует, значит, ваша тема не является проблемой, и вы должны перейти к шагу 3, в противном случае вы должны начать отладку вашей темы * 1.

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

4. Если после добавления темы и модулей сайт все еще реагирует быстро, начните добавлять конфигурацию, создавать типы контента, импортировать представления, настраивать меню и т. Д. Не забудьте протестировать ответ сайта после добавления каждого из них.

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

* 1 Тестирование тем: этот процесс может быть сложным в очень сложной теме, вот несколько советов:

1. Если вы ссылаетесь на любую внешнюю библиотеку js или css, попробуйте использовать ее локальную копию.

2. В вашем файле template.php проверьте наличие функции, которая может иметь более длинные или бесконечные циклы, а также функцию предварительной обработки и / или функции подключения темы.

3. Проверьте другой файл шаблона (page.tpl.php и т. Д.) И найдите необработанную PHP-обработку массивов и объектов.

4. Если вы используете «Виды» и просматривают файлы шаблонов, то проверьте и их тоже.

5. Всегда дважды проверяйте пути, оптимизируйте изображения, файлы js и css. Иногда js-файлы могут иметь большую высоту при использовании нескольких фрагментов кода в одном файле.

* 2 Модули тестирования : модули тестирования немного отличаются, потому что разрешено использование тяжелых манипуляций с PHP. Вот несколько указателей:

1. Модули, поддерживаемые сообществом (CCK, Views и т. Д.), Имеют очередь ошибок на drupal.org. Проверьте их, чтобы выяснить, существует ли какая-либо проблема, связанная с вашей проблемой, и если есть вероятность, что может быть исправление для ее исправления.

2. Собственный пользовательский кодовый модуль, хорошо, если вы закодировали, вы должны это исправить, верно? Дважды проверьте свою кодировку и проверьте использование функций по сравнению с api.drupal.org, вместо хука вы можете использовать функцию избыточного убийства.

3. Модуль общего пользовательского кода через Интернет, выполните действия, описанные в шаге 2, но на этот раз вы также можете связаться с автором исходного модуля и сообщить ему / ей о проблеме.

4. Если ваш сайт является обновлением (D5 -> D6 -> D7), проверьте скрипты миграции или обновления (обычно в файле module.install), вам может потребоваться дополнительный «индекс» в новой конфигурации таблицы, чтобы ускорить медленный SQL-запрос X ,

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

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

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

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

Удалите ссылки в таблице переменных, если модули больше не существуют.

Веб-APM, такой как newrelic, является лучшим инструментом для отслеживания проблем с производительностью. У меня были сайты, вызывающие одну или две строки кода, которые делали странные вещи, загружали ненужные массивы в странные времена и делали другие вещи, которые были довольно невидимыми, пока мы не выследили их с помощью APM.

Кто-то упомянул, что GoDaddy будет медленным. Многие облачные хостинговые компании также будут иметь эту начальную задержку, потому что такие сервисы, как AWS, имеют ее. Дешевле иметь автоматическую деприоризацию серверов, и этим серверам потребуется секунда или две, чтобы «проснуться».

Например, у Pagodabox есть 3-4 секунды на первый байт, пока сервер не проснется. Pagodabox фактически монетизировал, поддерживая сервер в активном состоянии, поэтому вы можете доплатить, чтобы «затянуть» ваш сайт.

Кроме того, CDN может помочь вам. Ваш сервер web / db не будет загружен обслуживанием кэшированных страниц или изображений. Хороший учебник здесь: http://wimleers.com/article/easy-drupal-cdn-integration-for-fun-and-profit

И ... WebPageTest делает меня счастливым. http://www.webpagetest.org/ Сравните время загрузки по всей планете и с различными веб-браузерами бесплатно. Используйте это, чтобы получить реальные результаты для любых изменений, которые вы делаете.

проблема может быть где угодно.

1. Убедитесь, что вы не включили режим отладки ни для одной темы или модуля. Например, во многих темах есть возможность восстановить реестр тем.
2. Если вы работаете на виртуальном хостинге, как Godaddy, тогда запрос 15 секунд в первый раз нормальный.
3. Преобразуйте ваш сайт или главную страницу в кодовую базу с помощью модуля экспорта Drush CTools . Это исключит любой вызов базы данных, и ваш сайт будет работать полностью с php.
4. Если у вас все еще возникают проблемы, используйте настройки Devel, включив query logи page timerопций на admin/config/development/devel. Посмотрите, какой из двух занимает больше времени для создания всей страницы.
5. Перезагрузите сервер, если ничего не работает.
6. В худшем случае установите XHProf, чтобы увидеть, где что-то идет не так.

Так вот как я исправил проблему для моей установки. Это не реальное решение, так как я не смог определить точный источник проблемы (если есть), но это хорошее решение

1) Агрегатный CSS (настройки кеша). Это уменьшило время ожидания вдвое

2) Установите для cron никогда (и запускайте его извне) - Примечание: у меня были «попытки запустить cron, пока он уже запущен». Я думаю, что он пытался запускать cron при каждом запуске, но, поскольку он потерпел неудачу, на странице cron упоминалась не последняя попытка, а скорее последний успех.

3) Настройте работу cron, которая будет вызывать Lynx на домашнюю страницу каждые 30 минут.

Все это на сервере общего хостинга. Это не оптимально, но это работает

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

Эти решения сохраняют отображаемые страницы при первом доступе, а затем подают предварительно обработанный html вместо того, чтобы проходить через весь процесс загрузки Drupal, создания страниц и создания тем, что позволяет сэкономить МНОГО времени, особенно на загруженных сайтах, но также и на таких сайтах, как вы. опишите, что «ложитесь спать» и слишком долго просыпаетесь.

Единственным реальным недостатком является то, что (по крайней мере, для Boost) вам необходимо очистить кеш при изменении содержимого сайта. Если вы хотите убедиться, что сайт полностью кэширован с текущим контентом, вы можете запустить drush cc all и затем периодически свернуть или wget для всего сайта через cron.