Дата последнего изменения: 23.09.2021
Итак, в результате тестирования были получены логи и графики нагрузки. А дальше, используя эти логи и графики, нужно понять, где узкие места, все ли устраивает и какие существуют способы повышения эффективности работы проекта.
Клиент может не знать всех терминов и инструментов тестирования. Нужно объяснить клиенту результаты тестирования понятным ему языком: «было столько-то, стало столько-то» и «хорошо стало или плохо», а также предложить ему решение проблемы, если она есть.
Нагрузили систему, и через некоторое время она перестала отвечать. Причина – безнадежно «заDDOSили» инструментами тестирования.
Чтобы это не произошло, нужно создавать разумную, похожую на боевую нагрузку:
В итоге пришли реальные пользователи на другие страницы сайта и … система перестала отвечать.
Поэтому при нагрузочном тестировании:
Здесь можно выявить различные ошибки. Например, верстальщик забыл добавить css-файл, NGINX отдает страницу с 404-й ошибкой через Apache средствами PHP (ошибка администратора). В итоге все слоты Apache заняты обработкой 404-й ошибки, попутно еще загружая сам сайт - получился типичный DDOS сайта. Решение этой проблемы - отдавать легкую статичную страницу с 404-й ошибкой сразу средствами NGINX.
Одним из основных инструментов анализа тестирования являются логи:
Также важная составляющая тестирования. Графики позволяют наглядно показать как вела себя система. Тестирование желательно проводить не менее суток.
Используя инструменты munin, cacti, pnp4nagios, просматриваем графики:Полезно написать несколько скриптов обработки логов:
Инструментов для этого достаточно, например: 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:
Рассмотрим эти шаги подробнее:
Статика отдается, как правило, очень быстро. NGINX проксирует запрос (к upstream), ждет и возвращает статусы:
200 ОК 500 Internal Server Error 502 Bad Gateway 503 Service Unavailable 504 Gateway Timeout
Нужно понять, какие статусы ошибок и когда возвращаются:
Если программист ошибся в коде - это обычно находится легко. Но бывают ошибки, возникающие из-за превышения потребления памяти скриптом (memory-limit) - желательно не превышать потребление памяти больше 512Мб. Такие системные скрипты могут не только сами завершаться, но и вытеснять, например, MySQL или Apache в swap, а если сервисы начнут уходить в swap, то происходит общая деградация системы и уменьшение производительности в целом.
Для отслеживания используются инструменты - Apache mod_status, php-fpm pm.status_path, ps/top.
Apache не может принять запрос от NGINX, он занят запросами в БД, запрос уходит в swap.
Инструменты для отслеживания занятых очередей: apache mod_status, netstat, atop/sar.
Основной причиной часто являются задержки в БД или в коде разработчик обращается на внешний сокет, который недоступен, и из-за этого скапливаются очереди между NGINX и Apache/php-fpm. Одним из решений может являться установка таймаута на работу с сокетом.
Способы отлавливания ошибок обращения с БД:
define("ERROR_EMAIL", "admin@site.ru, support@site.ru");
На этом этапе идет уже чистая отладка PHP:
Альтернативный логу медленных запросов php-fpm инструмент - Pinba, который рисует графики выполнения страницы или ее частей php.
На данном этапе:
После запуска нагрузки важно проверить, чтобы система работала в штатном режиме. Не перегружена ли текущая веб-система:
apachetop –f <лог nginx>, <лог apache>
- скорость запросов, есть ли проброс статики с Nginx на Apache - здесь в логе можно увидеть и поправить ошибки, если они есть. show processlist
– должно быть пусто или почти пусто.Если все в норме, то оставляем тестироваться проект на сутки. Если есть какие-то ошибки, то не нужно тратить время на тест, а нужно выявлять ошибки и после устранения начать тест заново.
Считаем процент ошибок в логах NGINX:
Нужно выяснить причины каждой ошибки. Очень важно исключить 50х ошибки.
Ошибки типа Segmentation fault (SIGSEGV) исправляются так:
-g
);Связываем с логом NGINX.
Связываем с логом NGINX.
Опираясь на технические результаты тестирования, важно правильно и понятно преподнести выводы теста клиенту.
Например, на основе данных построения страницы можно показать еще такой расчет:
90% хитов уложились в 2 сек, а 10% хитов - выполнялись более 2 сек при среднем времени всех хитов 0.3-0.4.
99% хитов уложились в 5 сек, 1% выполнялись более 5 сек и т.д.