Виведення контенту у власній вебсистемі: навантажувальний тест

Продовжуючи наші тести у листопаді 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, роботу з базою й завантаження медіафайлів, а не зводити всі витрати до одного показника.

Друга власна вебсистема: порівняльний тест 2007 року

Після першого тесту індивідуально розробленого сайту я вирішив перевірити ще одну таку систему. Адже власні розробки бувають різними, а швидкість може залежати й від наповнення сторінки. У листопаді 2007 року ми запустили на titan-r перевірку головної сторінки navstrechu.com.

Однаковий обсяг запитів — інший сайт

Параметри навантаження залишилися знайомими: один мільйон запитів, п’ять одночасно. Початкова довжина документа тут становила 20820 байтів, у відповіді зазначався nginx/0.4.13. За такого сценарію ми знову перевіряли одну адресу, а не повний шлях користувача сайтом.

Повний журнал вимірювання

root@titan-r:~# ab -c 5 -n 1000000 http://navstrechu.com/
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 navstrechu.com (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:        navstrechu.com
Server Port:            80

Document Path:          /
Document Length:        20820 bytes

Concurrency Level:      5
Time taken for tests:   2296.412062 seconds
Complete requests:      1000000
Failed requests:        0
Write errors:           0
Total transferred:      -462836480 bytes
HTML transferred:       -654836480 bytes
Requests per second:    435.46 [#/sec] (mean)
Time per request:       11.482 [ms] (mean)
Time per request:       2.296 [ms] (mean, across all concurrent requests)
Transfer rate:          -196.82 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:     5   10  12.0     10    5053
Waiting:        5    9   9.6      9    5051
Total:          5   10  12.0     10    5053

Percentage of the requests served within a certain time (ms)
  50%     10
  66%     12
  75%     13
  80%     14
  90%     17
  95%     18
  98%     21
  99%     23
 100%   5053 (longest request)

Мільйон запитів приблизно за 38 хвилин

Прогін завершився за 2296.412062 секунди — приблизно 38,27 хвилини. Середня швидкість становила 435.46 запиту/с. ApacheBench не зафіксував невдалих запитів або помилок запису.

Половина запитів уклалася у 10 мс, 95% — у 18 мс, 99% — у 23 мс. При цьому найдовша відповідь потребувала 5053 мс. Цей розрив між типовою та максимальною затримкою теж є частиною результату.

Від’ємні значення обсягу та швидкості передавання не можна трактувати як фізичний трафік. У журналі є аномалія лічильників; для встановлення її причини потрібні додаткові дані. Числа у первинному виводі збережено.

Чому висновок змінився

У попередньому тесті osan-koeln.net я отримав 190.38 запиту/с. Тут результат був приблизно у 2,29 раза вищим. Це вже показувало, наскільки різними можуть бути результати двох індивідуальних розробок, хоча причину різниці самі ці журнали не встановлюють.

Тоді я також записав оцінку, що цей сайт випереджав Joomla майже вдвічі. Для перевірки саме такого порівняння потрібен відповідний тест Joomla з узгодженими умовами. Натомість практичний висновок із двох власних систем був очевидний: одна назва класу «індивідуальна розробка» швидкодію не визначає.

Наступне запитання — сторінка з контентом

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

Тому мене зацікавило інше: як зміниться швидкість, якщо перевіряти внутрішню сторінку з контентом? Саме такий наступний крок міг показати різницю між швидкою головною та іншими сценаріями роботи сайту.

Власноруч розроблена вебсистема: тест головної сторінки 2007 року

У листопаді 2007 року я вирішив перевірити поширене твердження: чи справді стандартні CMS працюють швидше за індивідуально розроблені сайти? Для цього запустив тривалий тест головної сторінки osan-koeln.net на сервері titan-r.

Умови перевірки

ApacheBench виконав мільйон запитів із паралельністю 5. Головна сторінка мала довжину 33326 байтів, а сервер представлявся як nginx/0.4.13. Це перевірка однієї адреси, без переходів між розділами й відтворення різних дій відвідувачів.

Повний журнал тесту

root@titan-r:~# ab -c 5 -n 1000000 http://osan-koeln.net/
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:          /
Document Length:        33326 bytes

Concurrency Level:      5
Time taken for tests:   5252.648192 seconds
Complete requests:      1000000
Failed requests:        0
Write errors:           0
Total transferred:      -646738368 bytes
HTML transferred:       -1033738368 bytes
Requests per second:    190.38 [#/sec] (mean)
Time per request:       26.263 [ms] (mean)
Time per request:       5.253 [ms] (mean, across all concurrent requests)
Transfer rate:          -120.24 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       4
Processing:    12   25  45.3     23   10587
Waiting:       11   23  40.7     22   10581
Total:         12   25  45.3     23   10587

Percentage of the requests served within a certain time (ms)
  50%     23
  66%     26
  75%     29
  80%     31
  90%     37
  95%     43
  98%     51
  99%     60
 100%  10587 (longest request)

Що показали цифри

Прогін тривав 5252.648192 секунди — приблизно 87,54 хвилини. Середній результат становив 190.38 запиту за секунду. У журналі немає невдалих запитів або помилок запису.

Медіанний час відповіді становив 23 мс; 95% запитів уклалися у 43 мс, 99% — у 60 мс. Водночас найдовший запит тривав 10587 мс, тобто понад десять секунд. Тому однієї середньої швидкості замало, щоб описати всі затримки.

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

Порівняння зі стандартними CMS

Тоді я записав, що більшість перевірених мною CMS були швидшими, «Бітрікс» — повільнішим, а Joomla випереджала цей сайт приблизно в півтора раза. Проте в цій нотатці немає парного журналу Joomla з тотожними даними та налаштуваннями. Саме наведений прогін не дозволяє перевірити таке співвідношення.

Моя початкова гіпотеза була проста: масове рішення може вигравати завдяки більшій увазі до налагодження й оптимізації. Але сам факт індивідуальної розробки нічого не говорить про якість її оптимізації. На результат впливають реалізація сторінки, запити до бази, кешування та серверне оточення.

Висновок для вибору системи

Цей тест дав числовий результат для конкретного сайту у 2007 році, але не встановив переможця між усіма готовими CMS та індивідуальними рішеннями. Для такого порівняння потрібні однакові дані, сценарії й умови роботи. Метод читання показників описано в документації ApacheBench.