Перейти к содержимому

Фотография

Философия нагрузочного тестирования


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 3

#1 volk's

volk's

    Новый участник

  • Members
  • Pip
  • 25 сообщений
  • ФИО:Leo

Отправлено 28 июня 2012 - 09:01

Всем доброго времени суток. Кто-нить может объяснить плиз в чем разница, что мы запускаем один поток и что мы запускаем 500 потоков?
Когда мы проводим нагрузочное тестирование нам впринципе важно сколько tps выдерживает наш сервис, да? Вот только я не оч пойму в чем разница когда мы запускаем 1 поток и мы имеем пропускную способность 10 tps/sec и 1000 поток и 10 tps/sec, она расчитывается как среднее чтоли среди каждого потока
И вообще на что лучше стоит обращать внимание (что измерять), при использовании этого инструмента?
  • 0

#2 player1

player1

    Новый участник

  • Members
  • Pip
  • 61 сообщений
  • ФИО:Шайдров Павел
  • Город:Лимассол


Отправлено 28 июня 2012 - 12:25

насколько я понимаю (да поправят меня Гуру, если неправильно), единовременно один сервер может обрабатывать весьма небольшое количество транзакций. поэтому, чтобы определить максимальный TPS необходимо создать постоянную очередь транзакций, чтобы сервер, закончив обрабатывать одну транзакцию, сразу переходил к обработке следующей. Количество пользователей для создания такой очереди обычно (мной) определяется экспериментально: начинаешь с одного потока с минимальной задержкой, скажем, в 100 миллисекунд и увеличиваешь количество потоков до тех пор, пока TPS не перестанет ощутимо расти. Собственно говоря, полученный TPS -- тот максимум конкретного приложения в конкретной среде окружения, что и будет фактически результатом этого теста.
Исходя из этого ты можешь определить среднее значение о времени, которое требуется приложению на обработку одной транзакции: 1/maxTPS

Тест же с большим количеством пользователей имеет смысл только если определены два критерия: средняя задержка между запросами (например, предполагается, что реальный пользовател отправляет запрос примерно один раз в 2 минуты) и максимально допустимое время ответа. При этом ты начинаешь с какого-то количества пользователей и увеличиваешь его до тех пор пока, условно, 90%-95% запросов будут обрабатываться за допустимое время. При этом особенно следует следить за равномерностью нагрузки, чтобы запросы не накапливались в очереди. Результатом этого теста будет являться количество пользователей, которое конкретное приложение в конекретной среде может одновременно обслуживать.
  • 0

#3 fesd

fesd

    Опытный участник

  • Members
  • PipPipPipPip
  • 262 сообщений

Отправлено 29 июня 2012 - 06:25

"Кто-нить может объяснить плиз в чем разница, что мы запускаем один поток и что мы запускаем 500 потоков?"
Допустим, максимальная производительность, которую вам удалось достичь на вашем тестовом стенде, будет равна 10 зап/сек. И для достижении данной производительности достаточно уже 1 потока жметра. Замерьте загрузку процессора, потребления ОП, нагрузку на сеть и т.д. А теперь попробуйте пустить большее кол-во потоков, не ограничивая их скорость работы. Есть мнение, что циферки(проц,оп,сеть и т.д.) могут быть другими, ну и время ответа должно будет пропорционально кол-ву потоков расти. Еще большее кол-во потоков необходимо при проведения стресс тестирования, которое является одной из разновидностей тестирования под нагрузкой.

"Когда мы проводим нагрузочное тестирование нам впринципе важно сколько tps выдерживает наш сервис, да? "
Ага, еще важно какие ресурсы потребляет при этом. Также важно оценивать поведение системы под возрастающей нагрузкой, например увеличивая кол-во потоков. А еще важно как ведет себя сервис под сверхвысокими нагрузками. Важно как меняется производительность и потребление ресурсов при увеличении объемов данных в тестируемой системе - увеличение кол-ва записей в БД и т.п. Все важно.

"И вообще на что лучше стоит обращать внимание (что измерять), при использовании этого инструмента? "
Как и при использовании любого другого инструмента. Обратите внимание, что является "узким местом" в тестируемой системе. Например, тот же жметр под высокими нагрузками способен стать узким местом(сложный сценарий с большим кол-вом потоков).
Есть несколько разновидностей тестирования под нагрузкой - нагрузочное, стресс, длительное тестирования, тестирование производительности и др., и цели у них свои.
  • 1

#4 Wolonter

Wolonter

    Постоянный участник

  • Members
  • PipPipPip
  • 205 сообщений
  • ФИО:Макс
  • Город:Екатеринбург


Отправлено 30 июня 2012 - 11:42

Всем доброго времени суток. Кто-нить может объяснить плиз в чем разница, что мы запускаем один поток и что мы запускаем 500 потоков?
Когда мы проводим нагрузочное тестирование нам впринципе важно сколько tps выдерживает наш сервис, да? Вот только я не оч пойму в чем разница когда мы запускаем 1 поток и мы имеем пропускную способность 10 tps/sec и 1000 поток и 10 tps/sec, она расчитывается как среднее чтоли среди каждого потока
И вообще на что лучше стоит обращать внимание (что измерять), при использовании этого инструмента?


На JavaOne был доклад Драконы в домашнем хозяйстве и еще один Performance Engineering

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

Ресурсы - код приложения , память, CPU, i/o, конфиги сервера и приложнеия, сеть, СУБД.
Отклик - время выполнения операции (загрузки страницы).
Нагрузка - то, что мы фигачим jmeter'ом или иным.

Мы проводим одно измерение. записываем значения.
Дальше - фиксируем один параметр, меняем второй и смотрим, что станет с третьим.

То есть при тех же ресурсах меняем нагрузку и смотрим на отклик.
Или фиксируем нагрузку, рефакторим код, смотрим на отклик.
Или фиксируем отклик - т.е. удваиваем память/CPU/Диск, и увеличиваем нагрузку до тех пор пока отклик не станет прежним.

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

А самой большой проблемой было выяснить, скольки реальным операторам соответствует наша единица нагрузки.
Вторая проблема - это удержаться от тестирования браузеров, CPU, дисков, сети и продолжать тестировать именно приложение =)

Прикрепленные файлы


  • 0


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных