001. Нагрузочное тестирование типичного интернет-сервиса - Андрей Похилько

• Приветствие от Андрея.  

• Переход к делу без вводной части.  

• Благодарность за визит и обещание не разочаровать.  

• Нагрузочное тестирование важно для развития Рунета.  

• Рассказ будет состоять из двух частей и четырех главных пунктов.  

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

• Теория нагрузочного тестирования сложна и связана с теорией массового обслуживания.  

• Необходимость мостика между теорией и практикой.  

• Отрасль нагрузочного тестирования молодая, терминология и понятия спорны.  

• Нагрузочное тестирование часто путают с другими областями.  

• Нагрузочное тестирование является частью инженерии производительности.  

• Нагрузочное тестирование предоставляет информацию для принятия решений.  

• Нагрузочное тестирование должно давать информацию для всех.  

• Переход от тестирования к инженерии производительности.  

• Осознание этого перехода может мотивировать к изучению новых областей.  

• Задача нагрузочного тестирования - выяснить ключевые показатели производительности.  

• Емкость системы как ключевой показатель.  

• Параллелизм и его влияние на емкость системы.  

• Второй ключевой показатель - времена ответов.  

• Скорость, с которой потребители получают ответы.  

• Важность этого показателя обсуждалась ранее.  

• Времена ответов влияют на емкость системы.  

• Уменьшение времени ответа увеличивает свободное пространство на сервере.  

• Оптимизация времени ответа важна для удовлетворенности пользователей.  

• Надежность сервиса измеряется наработкой на отказ и временем восстановления.  

• Доступность сервиса зависит от инфраструктуры и менеджмента.  

• Масштабируемость системы проверяется на линейное увеличение емкости.  

• Критический ресурс определяет скорость работы и емкость системы.  

• Знание критического ресурса помогает планировать масштабирование.  

• Важно, чтобы критический ресурс совпадал в тестинге и продакшне.  

• Сервисы делятся на открытые и закрытые модели нагрузки.  

• Закрытая модель нагрузки: интенсивность запросов зависит от скорости ответа сервера.  

• Открытая модель нагрузки: интенсивность запросов не зависит от скорости ответа сервера.  

• Стейтлис системы не требуют сохранения контекста между сессиями.  

• Стейтфол системы сохраняют большое состояние на сервере.  

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

• Интернет-сервисы часто используют модели нагрузки, такие как стейтлис и стейтфул.  

• В системе могут быть как открытые, так и закрытые модели нагрузки.  

• Важно понимать закономерности нагрузки и тестировать сервисы с учетом этих моделей.  

• Яндекс использует как открытые, так и закрытые системы.  

• На фронтенде часто используется диспетчер для управления нагрузкой.  

• Важно иметь ожидания в отношении сервиса и рабочей нагрузки.  

• Необходимо знать рабочую нагрузку и запас для системы.  

• Важно учитывать пиковые нагрузки, такие как на новостных сайтах.  

• Время ответа и приемлемое время падений и восстановлений должны быть определены.  

• Инструменты играют ключевую роль в нагрузочном тестировании.  

• Сценарные и хит-бейс инструменты имеют свои преимущества и недостатки.  

• Хит-бейс инструменты позволяют создавать высокую нагрузку с меньшими ресурсами.  

• Инструменты должны уметь поддерживать как открытую, так и закрытую модели нагрузки.  

• Открытая модель позволяет инструменту адаптироваться к изменяющейся нагрузке.  

• Закрытая модель ограничивает количество воркеров и предотвращает перегрузку системы.  

• Открытая модель нагрузки демонстрирует жесткость для сервиса.  

• Закрытая модель отрабатывает расписание посетителей, снижая нагрузку при замедлении сервера.  

• Новички часто путаются в анализе результатов, не понимая разницу между моделями.  

• Телеметрия помогает понять состояние системы.  

• Хороший инструмент собирает любые метрики, представляемые в виде чисел.  

• Важно следить за системными метриками, такими как память, диск и процессор.  

• Инструмент должен позволять строить графики и агрегаты для тестов.  

• Возможность сравнивать тесты автоматически и сохранять их в облаке.  

• Хорошая система позволяет строить регрессионные последовательности и анализировать результаты.  

• Яндекс.Танк не генерирует нагрузку, а оборачивает другие генераторы.  

• Цель Яндекс.Танка — создать удобство для запуска и анализа тестов.  

• Ядро Яндекс.Танка организует конфигурирование и жизненный цикл теста.  

• Яндекс.Танк модульный, с гибким конфигурированием.  

• Группа модулей стрелялки генерирует нагрузку.  

• Используются различные стрелялки, такие как фантом и джи-метр, для различных типов тестов.  

• Python-стрелялка позволяет легко и быстро дорабатывать тесты.  

• Джиметр требует написания на Java и компиляции, что может быть сложно.  

• Python-стрелялка подходит для тестирования сложных протоколов и сценариев.  

• Яндекс.Танк собирает телеметрию по стандартным метрикам Linux.  

• Возможность использования однострочников для нестандартных метрик.  

• Поддержка систем без Linux и возможность работы с нестандартными метриками.  

• По умолчанию в Яндекс.Танке есть консольный вывод и веб-графики.  

• Возможность генерации HTML-графиков с JavaScript.  

• Поддержка артефактов и скриптов для агрегации данных.  

• Множество опций с дефолтами, но для стрельбы достаточно нескольких.  

• Возможность изменения важных опций через документацию.  

• Автостопы для остановки тестов при достижении стабильного состояния.  

• Возможность выполнения шелл-команд и оберток для веб-серверов.  

• Поддержка дополнительных модулей для расширения возможностей.  

• Простая архитектура и возможность написания собственных классов.  

• Нагрузочное тестирование как часть инженерии производительности.  

• Инструменты для генерации нагрузки и телеметрии.  

• Возможность доработки и улучшения Яндекс.Танка.  

• Вопросы и ответы о скорости работы сервера и интенсивности нагрузки.  

• Сбой - это когда сервер перестает отвечать согласно требованиям.  

• Сбои могут быть фатальными и требовать перезапуска сервиса.  

• Сбои могут возникать из-за перегрузки или внутренних проблем сервера.  

• Использование Яндекс.ДНК для тестирования асинхронных протоколов возможно.  

• Важно учитывать специфику протоколов и создавать соответствующие модули.  

• Примеры успешного тестирования с Кассандрой и другими системами.  

• Нагрузочные тестировщики сегментированы по сервисам.  

• В группе может быть до 13 человек, обслуживающих разные сервисы.  

• Разработчики активно привлекаются к самотестированию и нагрузочному тестированию.  

• Важно понимать, когда приходит последний из нескольких запросов.  

• Использование Selenium для тестирования клиентских сценариев.  

• Классическое нагрузочное тестирование работает на уровне сети, а не клиентских сценариев.  

• Подготовка включает определение оборудования и настройку доступов.  

• Важно иметь хорошую репутацию среди администраторов.  

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

• В сложных системах можно долго наращивать параллелизм.  

• В типичном сервисе число воркеров, равное числу ядер, выводит на предельную емкость.  

• В начале теста подключение новых воркеров не вызывает роста времени ответа.  

• После зоны комфорта начинается зона деградации, где времена ответов начинают расти.  

• Запросы начинают сталкиваться и выстраиваться в очередь.  

• Система выходит на полку, где времена ответов продолжают расти с каждым новым воркером.  

• Система достигает предела емкости, когда ресурсы кончаются.  

• В открытой модели нагрузка может достигать того же уровня.  

• Важно выяснить емкость системы на закрытой модели нагрузки.  

• В открытой модели нагрузки важно знать емкость системы.  

• Запросы быстро проходят зону комфорта, и времена ответов начинают расти.  

• Система может выйти из строя, если нагрузка превышает ее возможности.  

• На этапе тестирования на пределе система ограничена своим критическим ресурсом.  

• Важно найти и устранить критический ресурс.  

• Система часто приходит в непригодное для работы состояние.  

• Измеряем время ответа сервера, подавая нагрузку постепенно.  

• Сервер должен разогреться перед подачей нагрузки.  

• Уровень нагрузки выбирается из предыдущих тестов.  

• Тест на восстановление проверяет способность системы восстанавливаться после перегрузки.  

• Система должна уметь возвращаться в нормальное состояние после перегрузки.  

• Время восстановления измеряется с момента возвращения нагрузки в пределы возможностей системы до возвращения ответов в нормальное состояние.  

• Утечки памяти и файловых дескрипторов могут привести к проблемам на сервере.  

• Для проверки стабильности нужен длинный и интенсивный тест.  

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

• Длинные тесты помогают выявить долгосрочные процессы, такие как утечки памяти.  

• Пример: сервис с утечкой 8 МБ/с за ночь потерял 64 ГБ памяти.  

• Такие утечки требуют замены технологий.  

• Видео с пакистанцем, разбивающим орехи головой, используется для демонстрации теста.  

• Тест измеряет емкость в закрытой модели нагрузки.  

• Важно сравнивать ожидания с реальными результатами для оптимизации.  

• Процедура тестирования проста и направлена на простоту и понятность.  

• Метрики включают емкость, время ответов и восстановление после сбоя.  

• Эти данные важны для администраторов и бизнеса, чтобы избежать даун-таймов.