Представьте ситуацию: через банк ежесекундно проходит более 150 транзакций. Как можно быть уверенными, что такая система будет достаточно надежна и не откажет в 11 вечера в субботу, разочаровав клиентов?
Определить это можно с помощью нагрузочного тестирования. В этой статье я расскажу вам о том, какие есть особенности в нагрузочном тестировании банковских систем, на какие метрики следует обратить внимание и как его проводят в нашей компании.
Мы в компании Аквариус стремимся к тому, чтобы тестирование проходило без активного участия человека. Поэтому, продолжая предыдущую нашу статью про автоматизированное тестирование BMC: Тестирование BMC: Автоматизировать! Нельзя все руками, я расскажу про универсальное решение, которое мы создаем для получения показателей производительности BMC. Зачем это нужно и как мы пытаемся применять накопленный опыт в других направлениях, например при тестировании производительности нового для компании направления — СХД (Система Хранения Данных).
Привет! Меня зовут Евгений Гущин, я — исполнительный директор Smartup. За 20 лет работы в IT у меня было несколько забавных случаев. Сегодня расскажу, как мы героически поймали «русских хакеров».
Одним из критически важных этапов разработки веб-приложений является нагрузочное тестирование. Этот процесс необходим для выявления потенциальных узких мест в системе, а также для обеспечения того, что приложение способно выдерживать предполагаемое количество пользователей и запросов без ухудшения производительности.
Нагрузочное тестированиеЧитать полностью »
Привет, меня зовут Сергей Качеев, я старший разработчик в отделе сетевой инфраструктуры Яндекса. Сегодня я расскажу целый сетевой детектив о том, как мы искали баг, который убивал DNS сервер Unbound. Приготовьтесь, он будет долгим.
Тестирование — неотъемлемая составляющая разработки программного обеспечения. Независимо от того, насколько хорошо вы пишете код или насколько тщательно продуманным может быть первоначальный процесс тестирования, всегда есть вероятность, что что-то может ускользнуть.
У нас в Skyeng есть групповые уроки английского, они ограничены 10 участниками. Поскольку мы не используем промежуточного преобразования сигнала, а подключаем каждого пользователя, используя SFU, получается, что каждый генерирует один исходящий поток и принимает девять входящих потоков трафика. Также наши SFU сервера записывают уроки на случай каких-то сложностей с учителем (то есть для контроля качества) и для анализа различных показателей урока.
Мы учим не только английскому, но и математике, и другим предметам. Вдруг выяснилось, что для ряда занятий нужно собирать больше 10 человек, и при этом нужно иметь возможность разговаривать с каждым. Понятно, что учителю можно дать толстый канал в 1 Мбит/с, а ученикам — каналы потоньше: в 144p или 240p, например, но всё равно квадратичный рост трафика выглядел угрожающе.
Я решил протестировать Janus-видеосервер на 100 пользователях в канале и посмотреть, как быстро он упадёт. Ситуация осложнилась тем, что справки про это нет, примеров нет, и готовых решений тоже пока нет. Поэтому я и пишу.
Вы же тоже хотите посмотреть, как быстро он упадёт, да?
Читать полностью »
Если вы создаёте приложение, которое должно масштабироваться — а все мы надеемся, что наши приложения будут расти — то в определённый момент нам приходится разбираться, может ли оно это делать на самом деле. Именно тогда на помощь приходит нагрузочное тестирование: если вы хотите узнать, справится ли ваше приложение с крупными масштабами, то мы просто генерируем эти масштабы и проверяем! Звучит достаточно просто.
Но потом мы пробуем действительно сгенерировать нагрузку. Это делается легко, только если ваше приложение ужасно простое, ведь тогда можно использовать что-нибудь типа Apache JMeter для генерации повторяющихся запросов. Если у вас это получится, то я вам завидую: все системы, с которыми мне приходилось работать, сложнее и требовали более изощрённой схемы тестирования.
Если ваше приложение становится чуть сложнее, то вы переходите к инструментам наподобие Gatling. Они позволяют симулировать виртуальных пользователей, выполняющих различные сценарии, что намного полезнее, чем простая осада одного или нескольких URL. Но даже этого недостаточно, если вы пишете приложение, использующее одновременно WebSockets и HTTP-вызовы в течение долговременной сессии, а также требующее повторения по таймеру определённых действий. Возможно, я серьёзно недоглядел чего-то в документации, но мне не удалось найти способа, допустим, настроить периодическое событие, запускаемое каждые 30 секунд и выполняющее определённые действия при ответе на сообщение WebSocket, а также производящее действия по HTTP, и всё это в рамках одной HTTP-сессии. Я не нашёл такой возможности ни в одном инструменте нагрузочного тестирования (и именно поэтому написал на работе свой собственный инструмент, который надеюсь выложить в open source, если найду время на подчистку кода и отделения его от проприетарных частей).
Читать полностью »
Это — подборка утилит, составленная на основе рекомендаций резидентов Hacker News и GitHub. В список вошли: Locust, Vegeta, Slow_cooker, k6 и Siege. Ими пользуются инженеры из DICE, EA и Buoyant, а также разработчики Kubernetes и Load Impact. Расскажем об этих инструментах.
Мы задумались о построении инфраструктуры больших нагрузочных тестов год назад, когда достигли отметки в 12K онлайн-пользователей, работающих в нашем сервисе одновременно. За 3 месяца мы сделали первую версию теста, которая показала лимиты сервиса.
Ирония судьбы в том, что одновременно с запуском теста мы достигли лимитов на проде, в результате чего сервис упал на 2 часа. Это дополнительно стимулировало нас начать двигаться от проведения тестов от случая к случаю к созданию эффективной нагрузочной инфраструктуры. Под инфраструктурой я подразумеваю все инструменты для работы с нагрузкой: инструменты для запуска и автозапуска, кластер для подачи нагрузки, кластер, аналогичный проду, сервисы для сбора метрик и для подготовки отчётов, код для управления всем этим и сервисы для масштабирования.
