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

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

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

• 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, которые показывают, что происходило на сервере в конкретное время теста.

Графики

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

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

Cкрипты

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

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

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

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.
• Красивые графики и цифры.