52  /  97

Интерпретация результатов нагрузочного тестирования

Просмотров: 24449
Дата последнего изменения: 23.09.2021
Сложность урока:
4 уровень - сложно, требуется сосредоточиться, внимание деталям и точному следованию инструкции.
1
2
3
4
5

Итак, в результате тестирования были получены логи и графики нагрузки. А дальше, используя эти логи и графики, нужно понять, где узкие места, все ли устраивает и какие существуют способы повышения эффективности работы проекта.

  Частые ошибки

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

    Клиент может не знать всех терминов и инструментов тестирования. Нужно объяснить клиенту результаты тестирования понятным ему языком: «было столько-то, стало столько-то» и «хорошо стало или плохо», а также предложить ему решение проблемы, если она есть.

  • DDOS тестируемой системы
  • Нагрузили систему, и через некоторое время она перестала отвечать. Причина – безнадежно «заDDOSили» инструментами тестирования.

    Чтобы это не произошло, нужно создавать разумную, похожую на боевую нагрузку:

    • Очереди в NGNIX/PHP-FPM – не должны расти!
    • Система должна "свободно дышать": с помощью команд top и iostat –xm 5 отслеживать использование дисков и CPU.
  • Нагрузка только главной страницы при тестировании (а часто еще и с включенным кэшем).

    В итоге пришли реальные пользователи на другие страницы сайта и … система перестала отвечать.

    Поэтому при нагрузочном тестировании:

    • Нужно обращаться к разным страницам веб-системы.
    • Нужно загрузить демо-данные (реальный объем будущего проекта).
    • Важно использовать авторизованные хиты.
    • Также полезно проверять производительность загрузки статики (CSS, JS).

      Здесь можно выявить различные ошибки. Например, верстальщик забыл добавить css-файл, NGINX отдает страницу с 404-й ошибкой через Apache средствами PHP (ошибка администратора). В итоге все слоты Apache заняты обработкой 404-й ошибки, попутно еще загружая сам сайт - получился типичный DDOS сайта. Решение этой проблемы - отдавать легкую статичную страницу с 404-й ошибкой сразу средствами NGINX.

  Подготовка

Логи

Одним из основных инструментов анализа тестирования являются логи:

  • Лог jmeter – это логи основного инструмента тестирования: latency запроса, код http.
  • Лог nginx – latency общее, latency к upstream.
  • Лог apache/php-fpm – latency, код http, system/user time, memory.
  • Лог ошибок php - в нем должно быть чисто при сдаче проекта. Если есть ошибки,то их нужно исправлять.
  • Лог медленных запросов php-fpm - трейсы.
  • А также пригодятся логи sar или atop, которые показывают, что происходило на сервере в конкретное время теста.

Графики

Также важная составляющая тестирования. Графики позволяют наглядно показать как вела себя система. Тестирование желательно проводить не менее суток.

Используя инструменты munin, cacti, pnp4nagios, просматриваем графики:
  • Apache – запросы.
  • Nginx – запросы.
  • MySQL – запросы, потоки.
  • Процессор – user/system/iowait.
  • Память – использование и распределение.
  • Swap – использование.
  • Диски – latency, %util.
  • Сеть – tcp, трафик.

Cкрипты

Полезно написать несколько скриптов обработки логов:

  • Гистограмма времени запросов - количество и время запросов.
  • Гистограмма ошибок - какие ошибки и их частота.
  • Гистограмма расхода памяти - скрипт и объем памяти на скрипт.

Инструментов для этого достаточно, например: awk, bash, php, а также можно воспользоваться готовыми скриптами из блога «Битрикс» на Хабрахабре или связаться с нами по e-mail: serbul@1c-bitrix.ru.

Пример скрипта обработки лога на awk:
cat /var/log/www.access.log | awk -F# '{ zone = int($10/100)*100; hits[zone]++; } \
END { for (z in hits) {printf("%8s ms: %8s,%6.2f% ",z,hits[z],hits[z]/total*100);{s="";a=0;while(a++<int(hits[z]/total*100)) s=s"*";print s} } }' \
total="$TOTAL" - | sort -n

  Сценарий выполнения хита

Для правильного проведения теста и интерпретации результатов нужно знать, как работает система.

Очень важно понять, как проходит хит клиента к PHP:

  • Браузер клиента делает HTTP-запрос к Nginx
  • NGINX проксирует запрос к apache/php-fpm.
  • PHP обращается к БД.
  • PHP строит страницу и возвращает ее Nginx.
  • NGINX в http-ответе возвращает ответ в браузер клиента.

Рассмотрим эти шаги подробнее:

  1. Браузер клиента делает HTTP-запрос к NGINX

    Статика отдается, как правило, очень быстро. NGINX проксирует запрос (к upstream), ждет и возвращает статусы:

    	200 ОК
    	500 Internal Server Error 
    	502 Bad Gateway
    	503 Service Unavailable
    	504 Gateway Timeout
    

    Нужно понять, какие статусы ошибок и когда возвращаются:

    • PHP выполнялся слишком долго (редактировать таймауты, смотреть трейс php-fpm slow log …).
    • PHP остановился с fatal error - таких ошибок не должно быть!

      Если программист ошибся в коде - это обычно находится легко. Но бывают ошибки, возникающие из-за превышения потребления памяти скриптом (memory-limit) - желательно не превышать потребление памяти больше 512Мб. Такие системные скрипты могут не только сами завершаться, но и вытеснять, например, MySQL или Apache в swap, а если сервисы начнут уходить в swap, то происходит общая деградация системы и уменьшение производительности в целом.

    • NGINX не смог «достучаться» до apache/php.

    Для отслеживания используются инструменты - Apache mod_status, php-fpm pm.status_path, ps/top.

  2. NGINX проксирует запрос к Apache/php-fpm

    Apache не может принять запрос от NGINX, он занят запросами в БД, запрос уходит в swap.

    Инструменты для отслеживания занятых очередей: apache mod_status, netstat, atop/sar.

    Основной причиной часто являются задержки в БД или в коде разработчик обращается на внешний сокет, который недоступен, и из-за этого скапливаются очереди между NGINX и Apache/php-fpm. Одним из решений может являться установка таймаута на работу с сокетом.

  3. PHP обращается к БД

    Способы отлавливания ошибок обращения с БД:

    • Логгируем ошибки в БД: define("ERROR_EMAIL", "admin@site.ru, support@site.ru");
    • Лог и график медленных запросов к БД – анализируем, он не должен сильно расти.
    • График числа потоков в БД – смотрим максимум на графике.
    • Трафик к БД – график, большой трафик нельзя допускать, это, скорее всего, ошибка разработки.

  4. PHP строит страницу и возвращает ее Nginx

    На этом этапе идет уже чистая отладка PHP:

    • Смотрим ошибки в логе PHP.
    • Желательно использовать php-fpm, т.к в нем есть лог медленных запросов php-fpm, по которому видно, почему тормозит PHP.

      Альтернативный логу медленных запросов php-fpm инструмент - Pinba, который рисует графики выполнения страницы или ее частей php.

  5. NGINX в http-ответе возвращает ответ в браузер клиента

    На данном этапе:

    • Проверяем размер и сжатие страниц в логах.
    • Проверяем статику – идет через Nginx, в логах PHP – пусто.
    • Если есть 404 ошибка – смотрим статика или динамика.

  Запуск нагрузки

После запуска нагрузки важно проверить, чтобы система работала в штатном режиме. Не перегружена ли текущая веб-система:

  • /server-status (Apache mod_status) - свободные apache есть, БД в норме. Число ошибок и таймаутов смотрим в логах.
  • Nginx http_stub_status_module - убеждаемся, что Nginx не загружен.
  • apachetop –f <лог nginx>, <лог apache> - скорость запросов, есть ли проброс статики с Nginx на Apache - здесь в логе можно увидеть и поправить ошибки, если они есть.
  • Число потоков в БД – должно быть разумное:
    • mysql: show processlist – должно быть пусто или почти пусто.
    • Лог медленных запросов к БД – не растет.
  • CPU – нагрузка должна быть адекватная (50% - норма, 80-90% - уже много, система должна дышать).
  • Память – система не уходит в swap, swap не должен расти.
  • Трафик к клиенту и БД.
  • Нагрузка на диск.

Если все в норме, то оставляем тестироваться проект на сутки. Если есть какие-то ошибки, то не нужно тратить время на тест, а нужно выявлять ошибки и после устранения начать тест заново.

  Трактуем результаты

Nginx

Считаем процент ошибок в логах NGINX:

  • Ошибка 200 – 95%
  • Ошибки 50x – 5%.

    Нужно выяснить причины каждой ошибки. Очень важно исключить 50х ошибки.

    Ошибки типа Segmentation fault (SIGSEGV) исправляются так:

    • включаем сбор coredumps на сервере;
    • компилируем PHP/httpd с включенной отладочной информацией (флаг -g);
    • анализируем coredumps с помощью gdb;
    • удаляем, перенастраиваем "сбойные" модули/конструкции.
  • Latency (200 OK) для статики: среднее, 90%, 99%, распределение.
  • Время соединения с upstream больше 1 сек - это означает, сколько Nginx ждал пока upstream ответит. Смотреть и увеличить число Apache.

Apache/php-fpm

  • % ошибок в логах apache/php-fpm:
    • segfaults – бывают редкие случаи. Ищем причины.
    • fatal errors – не должно быть.
    • warnings - не должно быть.
  • php-fpm slow log.
  • latency (200 OK): cреднее, 90%, 99%, распределение.
  • Использование памяти скриптами нежелательно превышать порог в 512 Мб.

Связываем с логом NGINX.

База данных

  • Число медленных запросов – ищем откуда и какие запросы в нагрузке, простые запросы выполняются 5-10сек - это значит, что БД ушла в swap, CPU-загрузка и базе не хватало ресурсов.
  • Пики числа потоков в БД.
  • Анализ медленных запросов и их оптимизация.

Связываем с логом NGINX.

Для клиента

Опираясь на технические результаты тестирования, важно правильно и понятно преподнести выводы теста клиенту.

  • Число хитов (10 млн. хитов) - клиенту важно знать, что его проект выдерживает большое количество хитов в сутки.
  • Продолжительность тестирования (сутки) - сюда входят также и обычная работа сайта во время теста - бекапы, cron-задачи, import\export каталога и т.д.
  • Время построения страницы: 0.3, 0.4, 1.1... (0.3-0.4 сек - это норма).

    Например, на основе данных построения страницы можно показать еще такой расчет:
    90% хитов уложились в 2 сек, а 10% хитов - выполнялись более 2 сек при среднем времени всех хитов 0.3-0.4.
    99% хитов уложились в 5 сек, 1% выполнялись более 5 сек и т.д.

  • Распределение запросов по времени - гистограмма.
  • Процент ошибок (0.2%) – клиенты получили страницу об ошибке 50x.
  • Красивые графики и цифры.

5
Курсы разработаны в компании «1С-Битрикс»

Если вы нашли неточность в тексте, непонятное объяснение, пожалуйста, сообщите нам об этом в комментариях.
Развернуть комментарии