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

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

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

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

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

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

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

Среднее время хита – 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-серверов (веб-кластерные решения).