Продовжуючи наші тести у листопаді 2007 року, я перейшов від головної сторінки до сторінки з контентом: osan-koeln.net/our_city/. Хотілося побачити, що зміниться, коли сайт має вивести більше інформації.
Що перевіряли
Параметри залишилися такими самими: мільйон запитів і п’ять одночасних звернень. Довжина першого документа становила 91551 байт; у тесті головної сторінки того самого сайту було 33326 байтів. Відповідь формувалася для іншої адреси, тож ми зіставляли різні сценарії роботи однієї системи.
Повний журнал тесту
root@titan-r:~# ab -c 5 -n 1000000 http://osan-koeln.net/our_city/
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/
Benchmarking osan-koeln.net (be patient)
Completed 100000 requests
Completed 200000 requests
Completed 300000 requests
Completed 400000 requests
Completed 500000 requests
Completed 600000 requests
Completed 700000 requests
Completed 800000 requests
Completed 900000 requests
Finished 1000000 requests
Server Software: nginx/0.4.13
Server Hostname: osan-koeln.net
Server Port: 80
Document Path: /our_city/
Document Length: 91551 bytes
Concurrency Level: 5
Time taken for tests: 17246.269764 seconds
Complete requests: 1000000
Failed requests: 7
(Connect: 0, Length: 7, Exceptions: 0)
Write errors: 0
Non-2xx responses: 7
Total transferred: 1743045703 bytes
HTML transferred: 1356047278 bytes
Requests per second: 57.98 [#/sec] (mean)
Time per request: 86.231 [ms] (mean)
Time per request: 17.246 [ms] (mean, across all concurrent requests)
Transfer rate: 98.70 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 1
Processing: 0 85 128.2 82 25125
Waiting: 0 17 78.1 17 25043
Total: 0 85 128.2 82 25125
Percentage of the requests served within a certain time (ms)
50% 82
66% 91
75% 96
80% 99
90% 108
95% 118
98% 134
99% 151
100% 25125 (longest request)
Результат: приблизно 4,79 години
Прогін тривав 17246.269764 секунди — приблизно 287,44 хвилини, або 4,79 години. Середня пропускна здатність становила 57.98 запиту/с. Для головної сторінки раніше було 190.38 запиту/с: у цьому сценарії показник зменшився приблизно у 3,28 раза.
Медіана затримки становила 82 мс, 95% запитів уклалися у 118 мс, 99% — у 151 мс. Найдовша відповідь тривала 25125 мс. Тобто поряд із типовими короткими відповідями був і запит із затримкою понад 25 секунд.
Є сім відхилень за довжиною відповіді та сім відповідей поза діапазоном 2xx. Із цього підсумкового журналу не видно їхніх конкретних кодів і причин. Я тоді назвав результат рекордом повільності серед наших перевірок, але він стосується саме цієї сторінки й навантаження.
Де я шукав причини
За моїми тодішніми спостереженнями, основою рушія був один великий PHP-файл. Я пов’язував затримки з витратами на його обробку. Проте без налаштувань PHP і вимірювання часу виконання не можна стверджувати, що на кожному запиті відбувалася повторна компіляція. У сучасному PHP, наприклад, OPcache зберігає скомпільований байткод; наявність такого механізму в інсталяції 2007 року цим журналом не встановлено.
Інша підозра стосувалася обсягу роботи сторінки: на ній виводилося одразу десять рубрик, а для пагінації отримувалися додаткові рядки. Це був напрямок для перевірки запитів до бази, способу підрахунку записів і формування HTML. Однак окремих вимірювань цих операцій у нотатці немає.
Також я звернув увагу на великі, не оптимізовані за розміром фотографії. На цьому сайті вони зберігалися у файлах на диску, а не в базі. Для браузера такі файли могли впливати на повне завантаження сторінки, але наведена команда ApacheBench зверталася лише до /our_city/. Вона не відтворювала автоматичне завантаження всіх зображень, як браузер, тому вплив їхнього розміру саме на цей результат не доведений.
Висновок після перевірки
Тест показав, що швидкість головної сторінки не описувала всю систему. Сторінка з більшим обсягом контенту відповідала істотно повільніше. Щоб усунути причину, потрібно було окремо перевіряти формування HTML, роботу з базою й завантаження медіафайлів, а не зводити всі витрати до одного показника.
