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

Проблема полягає в тому, що коли я вперше заходжу на сайт, проходить приблизно 15 секунд, перш ніж з’явиться перша сторінка. Потім я можу пересуватися по сайту, і це дуже чуйно. Якщо я залишу його на годину або близько того, то повернуся до неї, перший запит знову дуже повільний.

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

Куди я йду далі?

Є три речі, які я хотів би перевірити.

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

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

По-третє, переконайтеся, що у вас є реальна стратегія щодо друку Cron . Особисто я б відключив автоматичний cron на "admin / config / system / cron" і налаштував би crontab для запуску щовечора. Ви також можете спробувати Elysia Cron, якщо вам дійсно потрібен тонший зернистий контроль над речами. Таким чином, ви можете виконувати необхідні завдання так часто, як вам потрібно, але нормальні завдання виконувати протягом ночі. Ваша початкова повільність могла бути від кронів, що відбуваються щогодини. Ви можете підтвердити це, подивившись, коли cron працює на "admin / messages / dblog" і намагаючись відповідати вашій повільності.

Ivanhoe123, напевно, має рацію: Drupal 7 постачається з "бідним mans cron", включеним за замовчуванням. Одним словом, це означає, що (раз у раз) крон запускається перед тим, як Drupal виводить сторінку, затримуючи все.

На виробничих майданчиках завжди намагайтеся використовувати справжню роботу. Докладніші технічні деталі див. На веб- сайті http://drupal.org/cron або поговоріть зі своєю хостинговою компанією.

Щоб відключити його, перейдіть до адміністратора / config / system / cron та виберіть "Ніколи".

Модуль Devel пропонує реєстрацію бази даних, щоб перевірити, чи є у вас тривалі запити.

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

Тільки з аромату питання, я відразу думаю про три (3) речі

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

MySQL Storage Engine

Якщо ви не використовуєте FULLTEXT для пошуку / індексації, я настійно рекомендую перетворити всі дані MyISAM в InnoDB. MyISAM не розроблений для використання декількох процесорів та декількох ядер. InnoDB значно покращився для багаторазового використання процесора, а також для читання / запису гіперточок.

Ось декілька публікацій, які я зробив з цього приводу в DBA StackExchange та на цьому веб-сайті стосовно налаштування MySQL для InnoDB Performance

• 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 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 не викликає сумнівів, можливо, вам доведеться перейти з печивом або лаком. Це дозволяє розробнику диктувати, скільки часу кешовані дані будуть знаходитися в оперативній пам'яті сервера. Звичайно, для цього потрібно буде покращити розвиток, щоб зробити вашу програму запам'ятовуваною / лаковою.

Блокування столу

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

Епілог

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

Я б використовував такі інструменти, як YSlow або Firebug тощо, щоб точно визначити, що відбувається під час завантаження вказаної сторінки та після завантаження зазначеної сторінки відразу після. Перевірте, чи це проблема кешування, а також перевірте, як вона функціонує, коли ви отримуєте доступ до сторінки як анонімний користувач, а потім як аутентифікований користувач. Порівняйте це з налаштуваннями продуктивності в Drupal.

Якщо це не проблема кешування, то використовуйте журнал запитів Devel, а також журнали MySQL, щоб побачити, що відбувається з wrt базою даних. Крім того, якщо у вас на сервері є кед-код для оптимізації або подібні кеші, що підвищують продуктивність, спробуйте вимкнути деякі номери з ними, а потім знову ввімкніть.

Звучить, як крон біжить.

Перевірте свої налаштування тут: admin / config / system / cron

Через це я ледь не відмовився від Drupal для свого останнього проекту.

Однак у мене повинно бути більше, ніж одна причина. Я ще не знайшов рішення "виправити все", яке працює кожного разу, коли ця проблема повстає.

Syslog та Ubuntu / Debain

Перший раз, коли я натрапив на переривчастий 15 секундний час завантаження, був під час роботи drupal на (Виділених, не поділених) системах на основі Debian / Ubuntu. Вимкнення модуля Syslog було для мене рішенням.

Як сказав @BetaRide, використання xDebug або якогось іншого PHP-профілера надзвичайно просвітлює.

Проблема все ще - вирішення

Що стосується інших моїх встановлень, я все ще втрачаю.

Це питання помітніше на моєму сервері розробки та моїх інсталяціях Drupal з низьким трафіком.

Як вирішення проблеми, я налаштував роботу із завантаженням cron, щоб завантажувати домашню сторінку сайтів кожні 60 секунд, а також крон-скрипт Drupal кожні 300 секунд. Це, очевидно, не є оптимальним, але я б швидше намагався або закручувати час завантаження 15 секунд замість людського відвідувача.

Багато людей припускають, що ця проблема може бути пов’язана з блокуванням синхронних фонових процесів , особливо пов’язаних із важкими завданнями на роботі з крон .

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

• Фоновий процес та його пакетні модулі дозволяють черзі фонових процесів Drupal оброблятись асинхронно, тому вони не блокуються. Це може зупинити проблему. Крім того, в комплекті модуля Background Process Apache Server в останньому розробнику є базовий, але вдосконалений звіт про інтерфейс користувача з можливостями нагляду, розблокування та перевірки часу запуску та ходу цих процесів. Це може визначити проблемний процес.
• Ultimate Cron ґрунтується на фоновому процесі, щоб дозволити завданням, що спрацьовують за допомогою крон, мати власні окремі асинхронні сценограми, кожну з яких можна відстежувати та зупиняти в інтерфейсі користувача. Окрім того, що відмінно підходить для вирішення важких завдань, що скорочують продуктивність, від звичайного очищення з низькими накладними витратами, він також дає вам звіт із зручною інформацією, такою як тривалість виконання кожної окремої задачі, що спрацьовує у хроні, під час їх останнього запуску, поточний стан, тощо. Це також може зняти блокування із та / або ідентифікувати проблемні процеси.

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

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

Також слід пам’ятати про інші пов'язані модулі плагінів, які зараз розробляються - наприклад, у складних випадках високої інтенсивності, Ultimate Cron Queler Scaler , що дозволяє на основі порогового дроселювання, може допомогти зменшити проблеми, пов'язані з кроном.

* немає приналежності, я просто дуже вражений користувачем їх роботи

Оскільки це мене ще раз вражає, я починаю досліджувати проблему. Я точно можу це підтвердити

1. виклик, drupal_cron_run()викликаний крон ядра бідолаха, додає ~ 5s до часу запиту на моїй машині розробки. Це може бути перевірено Розкоментуйте тести навколо виклику drupal_cron_run()в modules/system/system.moduleвsystem_run_automated_cron()
2. очищення всіх кешів додає ~ 2s до часу запиту на моїй програмі Dev. Це можна перевірити, зробивши 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, Перегляди тощо), мають черги проблем на 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 може допомогти вам. Ваша веб-сторінка не буде завантажена кешованими сторінками чи зображеннями. Хороший підручник тут: 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) Налаштуйте роботу з хроном, яка дзвонить на домашню сторінку Lynx кожні 30 хвилин

Все це на спільному хостинг-сервері. Це не оптимально, але це працює

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

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

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