Привет! Я Вадим Лунин, QA Manager в Альфа Банке в Беларуси. Это продолжение цикла статей по инструментам, которые мы используем для тестирования наших продуктов в Альфа Банке. В настоящей статье я хочу рассказать вам, какие инструменты мы используем для тестирования производительности и почему мы сделали такой выбор.

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

Как помочь ИТ-системам справиться с ростом трафика? Конечно, обеспечить эластичные вычисления и надежные каналы связи — сделать это можно с помощью облака. А еще на помощь приходит нагрузочное тестирование перед пиковыми событиями: вы должны знать, может ли приложение справиться с масштабированием или нет.

Для проведения нагрузочного тестирования следует определиться с методологией: наметить цели, продумать метрики и сценарии, подходы к интерпретации результатов. Разобраться с существенной частью этих задач должны специализированные открытые инструменты, и сегодня мы поговорим о некоторых заметных из них. В подборке: Locust, который позволяет писать тесты на Python, легковесный Drill, производительный Wrk, а еще — k6 и Tsung.

Linkerd, наша сервисная сетка (service mesh) для облачных приложений, по долгу службы обязана на протяжении длительного времени справляться с большими объемами сетевого трафика. Перед выпуском очередного релиза соответствие этому требованию необходимо тщательно проверять. В этой статье мы опишем стратегии нагрузочного тестирования и использованные нами инструменты, а также рассмотрим несколько обнаруженных проблем. В итоге будет представлен slow_cooker — написанный на Go инструмент нагрузочного тестирования с открытым исходным кодом, который был создан для выполнения длительных нагрузочных тестов и выявления проблем жизненного цикла (lifecycle issue identification).

Почти всех новых сотрудников Яндекса поражают масштабы нагрузок, которые испытывают наши продукты. Тысячи хостов с сотнями тысяч запросов в секунду. И это только один из сервисов. При этом отвечать на запросы мы должны за доли секунды. Даже незначительное изменение в продукте может оказать существенное влияние на производительность, поэтому важно тестировать и оценивать влияние своего кода на сервис.

В нашем сервисе рекламных технологий тестирование работает в рамках методологии Continuous integration, более подробно об организации которой мы расскажем 25 октября на мероприятии Яндекс изнутри, а сегодня мы поделимся с читателями Хабра опытом автоматизации оценки важных продуктовых метрик, связанных с производительностью сервиса. Вы узнаете, как доверить анализ машине, а не следить за ними на графиках. Поехали!

Эта статья была создана с неоценимой помощью нашего коллеги из Лаборатории Касперского, Игоря Щегловитова, инженера QA отдела исследований облачных технологий. Предисловие – от ahriman.

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

В этой статье мы расскажем, как писать код для нагрузочного тестирования «не-HTTP» протоколов на примере Apache Thrift с помощью таких инструментов, как JMeter и Gatling (часть 2). Тестировать будем микросервис, который должен справляться с 50K RPS. С одной нагрузочной машины постараемся достичь производительности, заявленной в этом твите:

Всем снова привет! Приглашаем на онлайн-встречу с Василием Кудрявцевым (директором департамента обеспечения качества в АО «РТЛабс»), которая пройдёт в рамках курса «Нагрузочное тестирование». И публикуем перевод статьи Michael Hunger — software developer and editor of Neo4j Developer Blog and GRANDstack!

Стандартные профайлеры Java используют либо инструментарий байткода, либо сэмплинг (рассматривая трассировки стека через короткие промежутки времени), чтобы определить, где было потрачено время. В обоих подходах есть свои недостатки и странности. Понимание результатов работы таких профайлеров само по себе искусство и требует большого опыта.

В оставшейся части этого руководства мы будем писать тесты для базы данных видеоигр (Video Game Database). Это приложение представляет собой, как вы наверное догадались, выдуманную базу данных видеоигр. Оно может похвастаться простым API, задокументированным с помощью Swagger, которое покрывает все HTTP-команды (Get, Put, Update, Delete) и поддерживает XML и JSON пейлоады.

Я рекомендую вам клонировать базу данных видеоигр и запускать ее локально. Для этого сначала клонируйте (или загрузите) репозиторий и откройте терминал в том месте, где вы сохранили его на своем компьютере. Оттуда вы можете запустить приложение с помощью:

Привет, читатель!

Меня зовут Василий Кудрявцев, и вот уже ~10 лет я занимаюсь нагрузочным тестированием, а из них последние 1,5 года – в компании РТЛабс.

И сегодня мы поговорим не об инструментах или общих подходах, а об области, которую обычно обходят стороной или собирают на коленке — тестовые стенды для нагрузочного тестирования.

Здесь, на Госуслугах, мы пока только конструируем мечту каждого нагрузочника — свой отдельный, выделенный, рабочий (!) тестовый стенд.  Особенно это мечта актуальна для небольших продуктовых команд.

Привет! Меня зовут Александра, я работаю в отделе тестирования производительности Тинькофф. Мы продолжаем наш цикл статей, посвященных работе Gatling с различными протоколами. Ранее мы уже рассмотрели работу с HTTP, JDBC и gRPC. В этой статье поговорим о работе Gatling с Kafka.