41  /  97

Как проводить нагрузочное испытание

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

  Для чего нагружать систему?

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

  • Невозможно заранее точно спрогнозировать поведение системы.
  • MySQL иногда плохо масштабируется при нагрузке.
  • Агенты Bitrix Framework и cron-скрипты могут "спутать все карты".
  • Ошибки в конфигурации сервера выявляются долго и не сразу.
  • Конкуренция потоков клиентов за ресурсы – файлы и т.п.
  • Синхронное обращение к внешним сокетам/сервисам.
  • Ошибки состыковки NGINX + Apache/PHP-FPM + MySQL + memcached.
  • Перегрузка сетевого стека NGINX + Apache/PHP-FPM.
  • Перегрузка сокета NGINX + Apache (unix domain socket).
  • "Рассыпания" прекомпилятора php.
  • и многое другое.

Нагрузочное тестирование нужно проводить всегда, хотя бы в базовом виде.

  Критерии оценки

В зависимости от того, что хочет клиент от нагрузки, тот вывод и детальность отчета получаем в конце теста.

Пример отчета 1
Гистограмма времени хитов:
хитов менее 0.5 сек – 95%, 
хитов дольше 10 сек – 0,01%.
Число ошибок < 0,01% 

Пример отчета 2
Среднее время хита – 0.3 сек.
Пиковое использование памяти скриптами - менее 128М.
Время тестирования – 48 часов.
Графики: munin по CPU, памяти, диску, трафику, детальные по mysql.

Примечание: Подробнее об интерпретации результатов нагрузочного тестирования можно прочитать здесь.

  Подготовка к нагрузочному тестированию

  • Устанавливаем инструменты анализа: munin, cacti.
  • Настраиваем логгер состояния системы. Например - atop.
  • Настраиваем опции логгирования NGINX, Apache, PHP-FPM, медленных запросов MySQL:
    • Для NGINX - логгирование таймингов на upstream/backend.
    • Для Apache/PHP-FPM - логгирование использования объема памяти.
    • Для PHP-FPM - включается лог медленных запросов с backtrace.
  • Также полезно написать несколько скриптов обработки логов:
    • Гистограмма времени запросов.
    • Гистограмма ошибок.
    • Гистограмма расхода памяти.
    Технологии: awk, bash, php.

Примечание: Обзор инструментов для создания нагрузочного тестирования можно прочитать здесь.

  Нагрузочное тестирование


  • Тестируем на реальных объемах

    Проводить нагрузочное тестирование нужно всегда на демо-данных, приближенных к реальным.

    Что в таком случае происходит с системой:

    • Важно «прикинуть» и воссоздать ожидаемый объем данных в БД.
    • Тестирование на выборках, похожих на реальные.
    • Компоненты могут отъедать много памяти на реальных выборках.
    • Запросы к БД становятся тяжелыми.
    • Запросы-убийцы и их влияние на веб-приложение
    • Уход системы в swap.

    Все эти процессы нельзя протестировать без нагрузки на этапе разработки.

    Инструменты мониторинга:

    • память, процессор - ps, top, free;
    • диски - iostat, atop.


  • "Утечка" контента

    В процессе нагрузки возможны такие случаи из-за ошибки разработчика, что NGINX файлы перестает видеть как статику и начинает отдавать через Apache, заполняя в итоге все его свободные слоты.

    Инструменты мониторинга - это лог-файлы:
    apachetop –f /var/log/nginx/access.log
    apachetop –f /var/log/httpd/access.log


  • "Зависания" стека tcp/ip

    Как выявить зависания стека tcp/ip:

    • На графике числа обращений к Apache - провал.
    • Резкий рост числа соединений между NGINX-Apache: netstat –ntop.
    • Логи состояния БД: show engine innodb status.
    • Логи netstat.
    • Лог медленных запросов MySQL.

    Частая ошибка в случае зависания стека tcp/ip кроется в запросах к БД.


  • "Зависания" memcached

    "Зависания" memcached происходит от резкого увеличения числа соединений к memcached.

    Для выявления можно использовать команду:

    netstat –ntop | grep 11211

    Решениями проблемы роста числа соединений могут быть:

    1. Настройка ядра:
      echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse 
      echo 15 > /proc/sys/net/ipv4/tcp_fin_timeout
      
    2. Настройка опций запуска самого memcached:
      memcached -d -p 11211 -u memcached -m 384 -c 10240 -P /var/run/memcached/memcached.pid
      
    3. Увеличение числа memcached-серверов (веб-кластерные решения).

Примечание: Пример создания тест-плана Jmeter на 5-10 млн. хитов можно посмотреть здесь.


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

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