Одноклассник задал такой вопрос:

Используйте JMeter для выполнения стресс-тестирования, 1000 групп потоков и последние несколько запросов зависают. В информации в интернете говорилось, что это может быть проблема с памятью, поэтому я поменял кучу памяти с 2G на 4G. Если попробую еще раз, все равно зависнет, есть ли способ настроить ресурсы для решения этой проблемы?

Я внимательно просмотрел его отчет по агрегации и обнаружил, что Max-rt достиг уровня 70 000+ мс, а между пиковыми и минимальными значениями диаграммы распределения времени отклика существует большой разрыв, поэтому я задал ему следующие вопросы:

• Зачем настраивать 1000 групп потоков?
• Каков бизнес-сценарий и какой тип услуги тестируется?
• Означает ли так называемое застревание, что запрос не возвращает ответное сообщение?
• Какова аппаратная конфигурация компьютера? В какой среде выполняется Тестирование производительности?

Ответ этого одноклассника был такой: Лестничные сценарии есть, и QPS сервисов почти одинаковые. Наконец-то хочу пробежать 1000, чтобы посмотреть.

Из его ответа видно, что у него нет большого опыта в практике тестирования производительности, а также он допустил наиболее распространенные ошибки, допускаемые новичками, а именно: высокий параллелизм без обдумывания, неструктурированное выполнение тестов (научное и разумное проектирование сценариев), не имеют глубокого понимания ни базовой теории тестирования производительности, ни принципов работы инструментов стресс-тестирования.

В этой статье рассказывается об анализе проблем с производительностью, а мнения предназначены только для справки.

Сначала давайте поговорим о параллелизме.

Многие новички учатся и практикуют Тестирование производительностичас,Это приведет к путанице в понятиях параллелизма, QPS, TPS и групп потоков. Некоторые студенты могут даже подумать, что,Количество зарегистрированных пользователей&Количество онлайн-пользователей=одновременно,Значение конфигурации группы потоков JMeter = параллелизм,Это понимание на самом деле является недоразумением.

Самая распространенная ошибка, которую допускают новички, — думать, что тестирование производительности — это найти инструмент для имитации параллельных запросов, постоянно увеличивать нагрузку и затем смотреть статистику мониторинга. На самом деле это не так. Приведем общий пример: с одним вызовом интерфейса проблем нет, но использование JMeter для отладки системы возвращает код: 500. Как справиться с этой проблемой?

Вообще говоря, когда код состояния, возвращаемый в ответе на запрос, равен 500, можно считать, что запрос успешен, но возвращаемое тело ответа не соответствует ожидаемому результату. На данный момент мы можем проанализировать проблему с двух точек зрения:

1. Проверьте журнал тестируемой службы, чтобы просмотреть подробную информацию о запросах и ответах, а также информацию о стеке ошибок.

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

Почему нам следует сравнивать содержимое запроса JMeter? Поскольку принцип моделирования запросов заключается в отдельном определении заголовка и тела запроса, все же существуют некоторые отличия от таких инструментов тестирования, как Postman. Во многих случаях запросы завершаются неудачно из-за небольших различий.

Новичкам в тестировании производительности я советую, прежде чем изучать инструменты стресс-тестирования, сначала иметь определенное представление о сетевых протоколах, таких как протоколы HTTP/TCP. В противном случае, просто научившись использовать инструменты стресс-тестирования, вы легко застрянете на пороге производительности. тестирование снаружи.

Далее поговорим о теме разработки сценариев тестирования производительности (стратегии выполнения).

Для новичков, Тестирование производительности Самое сложное на самом деле не в анализе и оптимизации узких мест,Но какНастройка параллельного выполнения сценариев и тестовые данные。Вот некоторые распространенные рабочие случаи,Сначала я представлю дело,Затем приведите пример стратегии тестирования (на примере JMeter).

Несколько слов об опыте:

1. В большинстве сценариев для первого стресс-теста рекомендуется использовать метод приращения градиента, что упрощает поиск точки перегиба производительности.
2. Фиксированное давление параллелизма применимо только тогда, когда другие условия остаются неизменными и изменяется только один влияющий фактор.
3. Обычно рекомендуется сначала выполнить градиент, а после обнаружения проблемы с позиционированием точки перегиба производительности проверить, эффективна ли оптимизация за счет фиксированного параллелизма.
4. Важна отдельная среда Тестирование производительности.,Если окружающая среда не может быть независимой,Рекомендуется прислушаться к просьбе лидера, провести стресс-тестирование волны статистических данных и подготовить отчет.
5. Не забудьте параметризовать тестовые данные и не используйте одни и те же данные или один и тот же пакет данных для повторных стресс-тестов (все функциональные тесты обновляют данные, не говоря уже о производительности).
6. Все вышеизложенное основано на опыте. Новички могут их копировать, но при возникновении проблем рекомендуется постоянно корректировать, пробовать, ошибаться и проверять, а не читать пьесу по сценарию.

Наконец, вернемся к названию этой статьи.,чат Общий подход к анализу проблем производительности。

С моей точки зрения, я думаю, что почти большинство технических проблем можно решить, выполнив следующие шесть шагов:

1-Объясните явление: что произошло(Запрос завис,Ответное сообщение не было возвращено).

2-Объясните факты: какие сцены и операции привели к этому явлению.(тестовая среда1000Стресс-тест группы потоков)。

3. Ищите данные. Найдите все данные, которые могут помочь вам проанализировать проблемы, с помощью журналов, мониторинга и т. д.(Содержит ли журнал сервера запись о доступе к вашему запросу?,Имеется ли стек ошибок или исключений; соответствует ли количество отслеживаемых неудачных запросов количеству запросов, не получивших ответного сообщения).

4. Проанализируйте проблему: выдвигайте гипотезы и мнения. Подтверждают ли данные ваши гипотезы и мнения. Если да, проанализируйте дальше.(Вместо непосредственного изменения конфигурации кучи службы на основе явления)。

5-Сделайте выводы: устраните неправильные выводы посредством анализа, попытайтесь исправить и проверить, а также понаблюдайте, изменяются ли данные в ожидаемом направлении.(повторить3и4шаг)。

6-Проверка оптимизации: подтвердите правильный и эффективный метод оптимизации и продолжайте оптимизировать и проверять до тех пор, пока ожидаемые цели не будут достигнуты или проблема не будет устранена.。