Вузьке місце в сервері чи в застосунку: як це виміряти

Час до першого байта на кожному стрибку

Теорії про повільний сайт легко сформувати і важко довести. Три вимірювання їх вирішують. Зніміть час до першого байта через публічний edge, ще раз напряму до origin в обхід edge, і ще раз на хості застосунку до localhost. Різниця між двома сусідніми показаннями є вартістю цього шару.

# through the edge
curl -s -o /dev/null -w 'dns=%{time_namelookup} tls=%{time_appconnect} ttfb=%{time_starttransfer}\n' https://site.example/

# direct to the origin, edge bypassed
curl -s -o /dev/null -w 'ttfb=%{time_starttransfer}\n' --resolve site.example:443:ORIGIN_IP https://site.example/

# on the host, nothing in front of the application
curl -s -o /dev/null -w 'ttfb=%{time_starttransfer}\n' http://127.0.0.1/

Усе, що залишається на localhost, є застосунком і сервісами, які він викликає. Шар з найбільшим розривом є тим, куди йде решта роботи.

Запас, поки болить

Читайте лічильники під час повільного періоду, а не після нього.

vmstat 1 5        # r (run queue), wa (I/O wait), st (steal), id (idle)
iostat -x 1 5     # await and aqu-sz per device
free -m           # the available column, not used

Довга черга виконання з низьким простоєм є хостом, обмеженим CPU. Високий I/O wait з високим await на пристрої є сховищем. Steal є сусідом на спільному гіпервізорі, який забирає цикли, яких хотів гість. Вільний CPU, доступна пам'ять і пристрої з низьким await під повільним сайтом означають, що хост чекає на щось, що хосту не належить: зовнішній виклик, блокування, запит, повільний з причин, не пов'язаних з обладнанням. Додавання обладнання в цей момент дає більш вільну машину, яка досі повільна.

Між цими двома є третя категорія, і вона поширена: пул. Сторінка статусу PHP-FPM показує чергу listen; черга запитів, що чекають, при вільному CPU означає, що кожен worker зайнятий, зазвичай заблокований на тому самому повільному виклику, і сайт повільний через стелю конфігурації, а не стелю ресурсів. Та сама форма проявляється як насичений пул з'єднань бази даних або повна черга backend у HAProxy. Хост невинний, а код ще не засуджений; розмір пулу і виклик, на який він чекає, є двома наступними показаннями.

Прочитайте трафік перед кодом

Журнал доступу каже, що це за проблема. Спочатку знайдіть журнал окремого vhost; типовий журнал може нести малу частку реального трафіку, і підрахунок над неправильним файлом дає впевнену неправильну відповідь.

tail -n 100000 access.log | awk -F'"' '{print $2}' | sort | uniq -c | sort -rn | head

Кілька URL, повторених тисячі разів, означають, що сайт викликає сам себе, і виправленням є кеш перед цими URL. Запити, що крокують у порядку sitemap, є краулером, і виправленням є обмеження частоти. Широке рівномірне зростання по багатьох URL є попитом, і виправленням є потужність.

Згорніть slow log і журнал запитів

Slow log є купою stack trace, доки йому не задано ключ. Увімкніть slow log PHP-FPM з порогом, який ловить запити, на які скаржаться користувачі, потім задайте кожному трейсу ключ за кадром, у якому він був заблокований, листком, і порахуйте. Ранжований список короткий, а нагорі зазвичай один зовнішній виклик або один запит до бази.

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

-- MySQL and Percona: by statement digest
SELECT digest_text, count_star, sum_timer_wait
FROM performance_schema.events_statements_summary_by_digest
ORDER BY sum_timer_wait DESC
LIMIT 10;

-- SQL Server: by query hash
SELECT query_hash, COUNT(*) AS plans, SUM(total_worker_time) AS cpu
FROM sys.dm_exec_query_stats
GROUP BY query_hash
ORDER BY cpu DESC;

Перш ніж писати будь-який індекс, перевірте реальну кількість рядків і індекси, які вже існують. Індекс на таблиці, якій він не потрібен, є повільнішим шляхом запису.

Читайте першоджерело, а не правдоподібну історію

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

Доведіть, потім перевірте тим самим вимірюванням

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

Що ми виправляємо і що повертаємо вам

Ми не змінюємо ваш код. Ми називаємо рядок, показуємо вимірювання, яке на нього вказує, і тримаємо сайт у роботі, поки ви його виправляєте.