Проблема с производительностью: Задержка при первом запросе

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

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

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

Куда я иду дальше?

36 голосов | спросил Kim Prince 6 J000000Friday12 2012, 03:51:08

16 ответов


16

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

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

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

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

ответил mpdonadio 3 AM000000120000004131 2012, 00:58:41
9

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

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

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

ответил Attiks 3 AM000000120000000431 2012, 00:21:04
8

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

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

ответил BetaRide 6 J000000Friday12 2012, 08:44:56
6

С самого начала вопроса я сразу же думаю о трех (3) вещах

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

Механизм хранения MySQL

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

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

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

Другим убедительным аргументом для преобразования всех данных MyISAM в InnoDB является то, как MySQL кэширует данные /индексы. В MyISAM Storage Engine кешируются только индексы. 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 /лаковым.

Блокировка таблицы

Эпилог

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

ответил RolandoMySQLDBA 7 PM00000090000004631 2012, 21:58:46
5

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

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

ответил 16 J000000Monday12 2012, 17:05:22
4

Похоже, что cron запущен.

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

ответил Aram Boyajyan 16 J000000Monday12 2012, 14:36:48
3

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

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

Syslog и Ubuntu /Debain

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

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


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

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

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

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

ответил Citricguy 3 AM00000050000003231 2012, 05:55:32
3

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

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

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

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

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

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


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

ответил user568458 6 AM000000120000000731 2012, 00:20:07
2

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

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

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

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

ответил BetaRide 6 PM000000120000000731 2012, 12:30:07
1

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

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

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

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

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

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

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

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

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

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

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

  4. Если вы используете файлы «Views» и views, то также проверяйте их.

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

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

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

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

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

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

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

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

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

ответил Emil Orol 3 AM00000090000005631 2012, 09:25:56
1

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

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

ответил cateye 5 AM00000020000001231 2012, 02:26:12
1

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

ответил beth 5 PM000000110000002931 2012, 23:35:29
1

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

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

Кроме того, CDN может помочь вам. Ваш веб-сервер /db-сервер не будет загружен при обслуживании кешированных страниц или изображений. Хороший учебник здесь: http://wimleers.com/статья /простой друпал-CDN-интеграция для развлечения-и-прибыль

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

ответил paul-m 7 PM00000080000004831 2012, 20:31:48
0

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

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

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

1) Совокупный CSS (настройки кэша). Это уменьшило задержку наполовину

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

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

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

ответил znat 6 PM000000100000001031 2012, 22:04:10
0

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

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

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

ответил jmarkel 8 PM00000050000001431 2012, 17:28:14

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132