Основы тестирования производительности

Question

У меня есть несколько основных вопросов, связанных с пониманием основ тестирования производительности.Я знаю, что при различных обстоятельствах мы могли бы захотеть провести - Стресс-тестирование - Тестирование на выносливость и т.д.Но моя главная цель здесь - обеспечить приличное время отклика приложения при наборе нагрузки, которая приближается к более высокому пределу или, по крайней мере, к нагрузке выше средней.

Мои вопросы заключаются в следующем:

1. Когда вы начнете планировать ожидаемое время отклика приложения;что вы считаете.Если это вообще первый шаг.Я имею в виду, что теперь у меня есть веб-приложение.Могу ли я просто вытащить цифру из воздуха и сказать: "Я бы ожидал, что приложению потребуется 3 секунды, чтобы ответить на каждый запрос".а затем займитесь выяснением того, чего не хватает моему приложению, чтобы получить такое время отклика?

2. ИЛИ все наоборот, и вы начинаете тест производительности с заданным набором оборудования и говорите: давайте посмотрим, какое время отклика я получаю сейчас, а затем смотрим на результаты и говорим: ну, прямо сейчас это 8 секунд, я бы хотел, чтобы это было максимум 3 секунды, так что давайте посмотрим, как мы можем оптимизировать это до 3 секунд?Но опять же, на 3 секунды не хватает воздуха?Я уверен, что масштабирование только машин не приведет к увеличению времени отклика.Время отклика увеличится только тогда, когда одна машина / сервер будет загружена и вы начнете кластеризацию?

3. Теперь для одного пользователя у меня есть время отклика в 3 секунды, но по мере увеличения нагрузки оно уменьшается экспоненциально;итак, где мне провести грань между "Мне нужно дополнительно оптимизировать код" (у которого есть верхний предел) и "Мне нужно увеличить масштаб моих серверов" (у которого тоже есть предел)

4. Каковы лучшие бесплатные инструменты для тестирования производительности и нагрузки?Я немного использовал Jmeter.Но есть ли что-нибудь еще, что является хорошим и с открытым исходным кодом?

5. Если мне нужно оптимизировать код, я начинаю профилировать конкретные потоки, которые отнимали много времени на ответы на запросы?

В принципе, я хотел бы посмотреть, как кто-то проходит от начала до конца тестирование производительности своего приложения.Любые ссылки или статьи были бы очень полезны.

Спасибо.

Answer 1

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

Также читайте Шаблоны и практики Microsoft для тестирования производительности.В этом руководстве показан комплексный подход к внедрению тестирования производительности.

феникс упомянул инструменты с открытым исходным кодом.

Answer 2

Прежде всего, вы можете прочитать

Рекомендации по ускорению работы Вашего веб-сайта

Для инструментов

Инструменты тестирования производительности с открытым исходным кодом

Производительность:Инструменты

Answer 3

Эта ссылка и это покажите пример и метод настройки производительности приложения, когда приложение не имеет каких-либо очевидных "узких мест".Это наиболее интуитивно работает с отдельными потоками.У меня нет опыта использования его в веб-приложениях, хотя другие люди это делают.Я согласен, что профилирование непросто, но я всегда полагался на эту технику, и я думаю, что это довольно просто / эффективно.

Answer 4

Прежде всего, правильно разработайте свое приложение.

Используйте профилировщик, посмотрите, где находятся узкие места в вашем приложении, и устраните их, если это возможно.ИЗМЕРЬТЕ производительность, прежде чем улучшать ее.

Answer 5

Я постараюсь предоставить базовое пошаговое руководство, которое можно использовать для внедрения тестирования производительности в вашем проекте.

1 - Прежде чем вы начнете тестирование вы должны знать объем физической памяти и объем памяти, выделенный для JVM, или что-то еще.Размер базы ДАННЫХ соберите как можно больше показателей для вашей текущей среды. Знающее вас окружение

2 - Следующим шагом будет определение общего объема производства БД и ожидаемого ежегодного роста.Вы захотите проверить, как ваше приложение будет вести себя через год, два, пять и т.д.,

3 - Автоматизируйте настройку среды, это очень поможет вам в будущем при регрессионном тестировании и проверке исправления дефектов.Таким образом, вам нужно иметь дампы базы данных для ваших тестов.С текущим (базовым) объемом за один год или за пять лет.

4 - Как только вы закончите, если соберете основную информацию - Подумайте о мониторинге ваших серверов под нагрузкой, возможно, у вас уже есть какое-нибудь решение для мониторинга, например http://newrelic.com/ это поможет вам определить причину снижения производительности (CPU / Mem / Количество потоков и т.д.,) Некоторые инструменты тестирования производительности действительно имеют встроенные системы мониторинга.

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

5 - Выберите инструмент Я думаю, что JMeter + http://blazemeter.com/ это то, что вам нужно на данный момент, в обоих есть много хороших статей и учебных материалов, для записи вашего скрипта я бы рекомендовал использовать расширение blazemeters Chrom вместо встроенного решения JMeters.Если вы все еще считаете, что вам не хватает знаний о том, как все делается в JMeter, я рекомендую приобрести эту книгу - Тестирование производительности с помощью JMeter 2.9 от Bayo Erinle

6 - Проанализируйте результаты, просмотрите план тестирования и предпримите соответствующие действия.