В Linux прекратилась поддержка SIMD-набора инструкций 3DNow! для процессоров AMD. Этот набор был выпущен компанией AMD в 1998 году вместе с процессорами K6 3D.

Меня зовут Валентина, я отвечаю за качество low-code платформы Efftech.Factory в компании Effective Technologies. В этой серии публикаций я честно расскажу о практиках нагрузочного тестирования (НТ), которые мы внедрили у себя. Будет признание реальных ошибок, настоящий процесс НТ и попытки его автоматизации. Те, кто предпочитает видео, могут посмотреть моё выступление на Spring QA Meetup 2024, благодаря которому появился этот текст. 

Почему я против жанра Success Story? 

В историях успеха нет места для тех глупых и болезненных ошибок, которые мы в действительности совершаем. Success Stories маловероятны. Каждая такая история — это лишь узкая тропинка, которая при определенных условиях может привести вас к победе… В остальных случаях может и не повезти!)

Другое дело — «Failure Stories». Это ситуации, которые вызывают понимающую улыбку и позволяют задуматься, как не допустить подобных ошибок у себя в проекте.

Ошибаться — это нормально. На ошибках учатся) Поэтому я хочу поделиться с вами опытом совершённых мной ошибок.

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

Меня зовут Вячеслав Смирнов, я ускоряю и тестирую инфраструктурные сервисы в Miro. Ещё я развиваю сообщество нагрузочников в telegram: делюсь там кое-какой экспертизой. В частности, если выполнять тесты производительности регулярно, по несколько раз в день, то вскоре в популярном хранилище тестов InfluxDB фильтровать результаты тестов производительности становится сложно. Сегодня я расскажу про 12 шагов, как можно ускорить InfluxDB. Основным из них является ускорение с помощью nginx кэширования. Пример использования кэширующего nginx, в качестве источника данных для Grafana можно найти тут. Все остальные примеры, которые мы будем разбирать я вынес сюда. А слайды оставил здесь.

Возможно, самая важная часть нашей работы — это осмысление данных, в первую очередь чисел. Как правило, мы смотрим на показатели, которые получаем благодаря инструментам нагрузочного тестирования, мониторингу серверов и приложений, логам или запросам к базе данных. Цель состоит в том, чтобы понять поведение системы, но иногда эта информация вводит нас в заблуждение.

Всем привет, меня зовут Сергей, я занимаюсь тестированием производительности. Недавно поднялся вопрос в выборе инструмента для воспроизведения довольно интенсивной нагрузки, в основном по HTTP. Инструментов для тестирования производительности сейчас представлено довольно много, в том числе многие из них являются Open Source — проектами и доступны бесплатно. Стало интересно, какой же инструмент справится с подобной задачей лучше, сможет воспроизвести большую нагрузку затратив меньше ресурсов.

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

Введение

Нагрузочное тестирование представляет собой вид нефункционального тестирования и предполагает проверку работы системы под высокой нагрузкой. Может показаться, что это звучит скучно, но на самом деле весь процесс планирования, оценки и проведения нагрузочных тестов системы похож на решение сложной головоломки, и это может быть очень увлекательно.

Нагрузочное тестирование — это своего рода искусство. Написание тестовых сценариев — это только половина дела. Тестовый стенд необходим для того, чтобы как можно точнее имитировать реальных пользователей. Фактически, необходимо следующее:

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

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

Обеспечение надежного функционирования системы при развертывании обновления системы требует запуска тестов разного уровня - от модульных тестов отдельных компонентов до интеграционных тестов, проверяющих в staging-окружении работу системы в целом. Но не менее важны для оценки готовности системы к большой кратковременной пиковой нагрузке (или злонамеренным атакам) выполнение нагрузочных тестов. В июле 2021 года компания Grafana Inc приобрела продукт k6, который изначально был ориентирован на запуск высокопроизводительных распределенных нагрузочных тестов, и это положительно повлияло на его дальнейшее развитие как встраиваемого инструмента для запуска тестов в облачных инфраструктурах или Kubernetes. В этой статье мы рассмотрим один из возможных сценариев использования k6 для тестирования сервиса в конвейере CI/CD.

Всем привет! В данной статье расскажу о том, как мы решали задачу нагрузочных тестов для сервиса поиска, как познакомились с замечательным K6 и о том, как ведет себя облачный Elastic Search под нагрузкой.

Привет! Меня зовут Максим Колесников. Я работаю в центре компетенций нагрузочного тестирования блока обеспечения и контроля качества выпуска изменений в «РСХБ-Интех» — IT-компании АО «Россельхозбанк». И как-то раз у меня возникла мысль: «А не выкинуть ли нам JMeter и переписать все на k6?». Что из этого вышло, читайте далее.

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

Привет! Меня зовут Юля Шамина, я руководитель IT-проектов в СберМаркете. Хочу поделиться нестандартным по всем меркам кейсом, как мы подготовили наши сервисы к высоким предновогодним нагрузкам за 3 месяца благодаря челленджу внутренней команды нагрузочного тестирования. 

Эта статья не про успешный успех, а про то, как и зачем привлекать подрядчика, если вопросом уже занимается внутренняя команда.  А ещё про страх неизвестности, мучительную настройку процессов и то, как в конце концов показать высокие результаты в сжатые сроки с минимальным количеством факапов.

Если бы можно было описать этот проект одной цитатой — «Это было смело, чертовски смело!»

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

Привет, меня зовут Георгий Ломакин, и я инженер по нагрузочному тестированию в компании Picodata — разработчике одноимённой NewSQL СУБД. В этой статье я поделюсь своим опытом нагрузочного тестирования и расскажу, как мы строили эту практику с нуля.

Мы выбираем распределённые системы за производительность и надёжность. Однако без постоянного нагрузочного тестирования и анализа отчётов после него, и то и другое лишь обещания. Конечно же, нагрузочное тестирование обязательно и в нашей команде, разрабатывающей распределённую NewSQL — базу данных Picodata.

В этой статье мы рассмотрим, что такое тестирование производительности, рассмотрим несколько подходов, которые можно использовать для лучшего понимания того, как приложение ведёт себя при различных уровнях нагрузки. Мы также познакомимся с K6 — мощным инструментом для тестирования производительности, специально разработанным для современных процессов разработки, и продемонстрируем его использование на примере. Этот инструмент предлагает очень удобный опыт для пользователей, обладающих базовыми знаниями JavaScript или TypeScript, значительно упрощая процесс тестирования производительности.

Анализ результатов нагрузочного тестирования k6 требует не только сбора метрик, но и их грамотной визуализации. Избыточный поток данных может усложнить процесс принятия решений, поэтому важно выбрать ключевые показатели и подходящий инструмент для их отображения. В этой статье рассмотрим, какие метрики стоит отслеживать, как их визуализировать с помощью Grafana, CSV, JSON и других форматов, а также поделимся рекомендациями по эффективному анализу производительности.

Привет, Хабр, это снова Валентина, которая отвечает за качество low-code платформы Eftech.Factory в компании Effective Technologies. Представляю вторую статью из серии публикаций о наших практиках нагрузочного тестирования (НТ). Первую, про поиск оптимального процесса НТ, можно прочесть здесь. На этот раз я собираюсь поделиться рекомендациями по автоматизации рутины и отчётности. 

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

Чтобы достичь этих целей, я выработала для себя антистрессовый чек-лист из пяти пунктов.

По ним мы сегодня и пойдём.