Tps нагрузка что это
Анализ результатов нагрузочного тестирования
С каждым днем в мире становится все больше и больше инструментов для проведения нагрузочного тестирования. Собственно, и сам интерес к этой теме начинает возрастать.
Основная задача инструмента нагрузочного тестирования — подать заданную нагрузку на систему. Но кроме этого есть еще одна, не менее важная задача — предоставить отчет о результатах подачи этой нагрузки. Иначе мы проведем тестирование, но ничего не сможем сказать о его результате и не сможем достаточно точно определить, с какого момента началась деградация системы.
В настоящий момент наиболее популярными инструментами тестирования являются Gatling, MF LoadRunner, Apache JMeter. Все они обладают возможностями как генерации готовых отчетов по проведенному тестированию, так и отдельных графиков или сырых данных, на основе которых строится уже сам отчет.
Прежде чем писать любой отчет, нужно понять, для кого мы его пишем и какую цель преследуем. Нет никакого смысла добавлять множество графиков времени отклика приложения в отчет по каждой операции, если ваша цель — определить, есть ли утечки памяти, зафиксирована ли нестабильная работа во время теста надежности, или если вам нужно сравнить два релиза между собой в рамках регрессионного тестирования. Для ответа на эти вопросы вам хватит всего пары графиков, если, конечно, вы не зафиксировали проблемы и не хотите в них разобраться. Поэтому, прежде чем создавать отчет, подумайте, а точно ли вам нужно добавить все графики в него или лишь наиболее показательные и дающие ответ на цель тестирования. Также набор графиков и их анализ для отчета зависят от выбранной модели нагрузки — закрытой или открытой, так как разные модели дадут разные фигуры на графиках.
Мы в Тинькофф активно используем инструмент Gatling, поэтому на его примере расскажем, как создать отчет вашей мечты и куда следует смотреть при его анализе. Также сразу хочу заметить, что почти все графики, описанные в статье, можно получать в режиме онлайн с помощью связки вашего инструмента с Grafana. Это наиболее удобный инструмент для создания отчетов «на лету», с помощью сконфигурированного заранее дашборда. Более того, это позволяет более быстро создать почти любой график на основе отправленных вами данных. Уже сейчас есть готовые дашборды почти для всех инструментов нагрузочного тестирования. Графики для других инструментов — MF LoadRunner и Apache JMeter — тоже будут приведены, их анализ строится по аналогии с Gatling.
Основные метрики
Индикаторы
Показывают количественное и процентное распределение времени отклика запросов по группам. Графики этого типа удобно использовать, чтобы дать быструю предварительную оценку результатам тестирования без более глубокого анализа остальных графиков.
Пороги для перехода из группы в группу задаются заранее на основе экспертной оценки или SLA (нефункциональных требований). Например, может быть три группы:
Метод APDEX позволяет использовать индикаторы в регрессионном тестировании для сравнения релизов: так сразу видно, насколько хуже или лучше стал релиз в общем. К сожалению, этого графика нет из коробки в MF LoadRunner и Apache JMeter, но его легко создать с помощью дашборда Grafana.
Таблица с временем отклика
По умолчанию Gatling строит таблицу по перцентилям, среднему и максимальному времени отклика, а также по ошибкам. По ней отслеживается выход за пределы SLA (превышение нефункциональных требований). Обычно в SLA указывают перцентили 95, 99 и процент ошибок. Таким образом таблица позволяет получить быструю оценку результатов тестирования.
Если группировать запросы в виде транзакций, можно увидеть в таблице как оценку отдельных запросов, так и оценку всей группы и транзакции сразу.
| HTML Gatling Report | |
| MF LoadRunner также создает таблицу сам в блоке Analysis Summary Report и называется Transaction Summary |  |
| В Apache JMeter эти данные можно найти в Aggregate Report |  |
График Virtual Users
Обычно измеряется в штуках и показывает, как пользователи заходят в приложение, тем самым иллюстрируя реальный профиль нагрузки. Стоит сразу оговориться, что для MF LoadRunner и Gatling эти графики показывают количество Virtual Users, а для Apache JMeter — количество Thread.
График используют для контроля правильности подачи нагрузки. Необходимо, чтобы ваш расчетный сценарий соответствовал тому, что вы подали на систему в реальности. Например, если вы видите на графике большие отклонения от планируемого сценария в верхнюю сторону, значит, что-то пошло не так: ошибка в расчете, запущено больше, чем нужно, копий инструмента нагрузки и так далее. Возможно, дальнейшие графики уже нет смысла анализировать, так как вы подали на 100 пользователей больше, чем планировали, а система изначально проектировалась для работы лишь 10 пользователей.
Этот график разделяется на два вида:
| HTML Gatling Report | |
| В MF LoadRunner этот график называется Running Vusers |  |
| В Apache JMeter график называется Active Threads Over Time и не входит в стандартную поставку, но его можно бесплатно скачать на сайте JMeter-Plugins.org |  |
График Response Time
Чаще всего измеряется в миллисекундах — показывает время ответа на запросы к приложению. Время отклика не должно превышать SLA. Этот график является основным инструментом для поиска точек деградации при проведении нагрузочного тестирования.
Если на графике видны пики, значит, в этот момент приложение не отвечало по какой-то причине — это может являться отправной точкой для дальнейших исследований. Время отклика должно быть равномерным, без пиков для всех операций на протяжении всей ступени нагрузки, а также коррелировать с увлечением нагрузки. Gatling не содержит график «чистого» (среднего, не агрегированного) времени отклика, в отличие от других инструментов.
Кроме графика времени ответа каждого запроса удобно показывать также линию с суммарным временем ответа (Total Response Time). Если наложить график подаваемой нагрузки (VU/RPS), можно отслеживать корреляцию с увеличением времени отклика от увеличения подаваемой нагрузки (VU/RPS). В Apache JMeter этот график называется Response Times vs Threads.
Далее пойдут графики, на которых может быть множество линий, каждая из которых отображает свой сценарий или запрос. Если у вас сложный тест со множеством операций и нелинейным профилем, советуем отражать в отчете лишь наиболее показательные запросы или группы запросов. Как вариант, можно отражать лишь запросы, превысившие SLA/SLO, чтобы не засорять график и отчет.
| В MF LoadRunner график называется Average Transaction Response Time и показывает среднее время для транзакций |  |
| Для Apache JMeter график существует в двух вариантах в расширенном пакете с сайта JMeter-Plugins.org и называется Response Times Over Time и, по умолчанию, Response Time Graph. Более наглядный и удобный, на мой взгляд, — первый вариант |  |
Вариации графика
Возможна модификация, в которой применяются перцентили времени отклика и добавляется линия среднего времени отклика по всем запросам. Использование перцентилей здесь будет более правильным решением, так как среднее время отклика очень чувствительно к резким выбросам.
В тестировании производительности чаще всего используется 95 и 99 перцентиль для большей наглядности. Однако, если вы все же смотрите среднее время отклика, вам стоит учитывать при этом стандартное (среднеквадратичное) отклонение.
| HTML Gatling Report | |
| Для MF LoadRunner график будет называться Transaction Response Time (Percentile) |  |
| Также вы можете получить и перцентили для Apache JMeter с помощью графика Response Times Percentiles из этого же расширенного набора |  |
Распределение Response Time
Также есть прекрасные графики, показывающие зависимость распределения времени от количества запросов.
Этот вид графиков чем-то напоминает индикаторы, но показывает более полную картину распределения времени, без обрезки перцентилями или другими агрегатами. С помощью графика можно более наглядно определить границы для групп индикаторов. У MF LoadRunner такого графика нет.
| HTML Gatling Report для каждого запроса | |
| Есть еще один вариант распределения времени выполнения запроса от количества запросов в разрезе успешных и ошибочных запросов для всего теста | |
| Для MF LoadRunner данный график будет называться Transaction Response Time (Distribution) и показывать распределение для транзакций |  |
| В Apache JMeter тоже есть этот график в расширенном пакете и называется Response Times Distribution |  |
Latency
| В Apache JMeter этот график присутствует лишь в расширенном наборе и называется Response Latencies Over Time |  |
Bandwidth
Аналогично метрике выше можно выделить параметр Bandwidth (килобит в секунду) — ширину пропускания канала. Он показывает, какой максимальный объем данных может быть передан за единицу времени.
Изменяя этот параметр на инструменте нагрузки можно моделировать различные источники подключений к приложению: мобильная связь 4G или проводная сеть. В бесплатной версии Gatling этого графика нет, он есть лишь в платной версии Gatling FrontLine. Этот график из коробки есть лишь в MF LoadRunner, находится в том же блоке, что и Latency, и называется Average Bandwidth Utilization Graph.
График Request Per Second
Измеряется в штуках в секунду — показывает количество запросов, поступающее в систему за 1 секунду.
График показывает, сколько запросов может выдержать ваша система под нагрузкой, и он является также основным графиком для построения отчета. По нему также отслеживается выход за пределы SLA, так как с ростом нагрузки при прохождении точки деградации или локальных экстремумов может наблюдаться провал, а затем резкий рост. Чаще всего это связано с тем, что, когда приложение начинает деградировать, запросы тоже начинают копиться на входе в приложение (появляется очередь), затем приложение выдает им какой-то ответ или запросы падают по тайм-ауту, что вызывает резкий рост на графике — ведь получен ответ.
| HTML Gatling Report | |
| В MF LoadRunner график называется Hits per Second |  |
| Для Apache JMeter существует график Hits per Second из расширенного пакета |  |
Измеряется в штуках в секунду и показывает количество транзакций (в рамках транзакции может быть множество запросов) за 1 секунду.
Например, транзакция «вход в личный кабинет» включает следующие запросы: открытие главной страницы, ввод логина, пароля, нажатие кнопки «отправить», переадресацию на приветственную страницу — в единицу времени. В Gatling график можно получить лишь с помощью применения Grafana, так как для групп в HTML-отчёте строятся графики лишь по времени отклика.
| MF LoadRunner — Transactions per Second |  |
| Для расширенного пакета Apache JMeter — Transactions per Second |  |
График Errors
Обычно измеряется в rate (штук в секунду) — график показывает рост количества ошибочных запросов. Также удобно измерять значение в процентах от общего числа запросов. По этому графику отслеживается выход за пределы SLA по количеству или проценту ошибок.
Если наложить график Response Time, можно увидеть, как увеличение ошибок влияет на рост времени ответа приложения.
Gatling по умолчанию не имеет отдельного графика, отображающего лишь ошибки. В Gatling он совмещен с графиком VU и сразу показывает, как рост нагрузки сказывается на росте числа ошибок, и помогает обнаружить порог, с которого идет превышение SLA или вообще появляются ошибки. В Apache JMeter также нет отдельного графика, он совмещен с графиками количества транзакций.
| HTML Gatling Report | |
| В MF LoadRunner этот график называется Errors per Second |  |
HTTP responses status
Возможно также выводить на график распределения количества ошибок по кодам ответа приложения — удобно использовать для классификации ошибок.
Русские Блоги
Пропускная способность системы, TPS (QPS), параллелизм пользователей, концепции и формулы тестирования производительности
1. TPS:
Транзакций в секунду (количество транзакций, обрабатываемых в секунду), то есть количество транзакций, обрабатываемых сервером в секунду. TPS включает одно входящее и одно исходящее сообщение, а также один доступ к базе данных пользователя. (Business TPS = CAPS × среднее TPS на звонок)
Как правило, производительность системы оценки измеряется количеством технических транзакций, выполняемых за секунду. Общая производительность системы зависит от значения TPS модуля с самой низкой производительностью.
2. QPS:
Соответствует количеству запросов в секунду, которое представляет собой максимальную пропускную способность.
PS: Ниже приведены основные понятия и формулы расчета теста производительности, запишите:
Один. Элементы измерения системы проглатывания:
Пропускная способность (способность выдерживать давление) системы тесно связана с потреблением ЦП запроса, внешними интерфейсами, вводом-выводом и так далее. Чем выше потребление ЦП на один запрос, тем медленнее влияние внешних системных интерфейсов и ввода-вывода, тем ниже пропускная способность системы и наоборот.
Несколько важных параметров пропускной способности системы: QPS (TPS), одновременное количество, время отклика.
QPS (TPS): количество запросов / транзакций в секунду
Количество одновременных проблем: количество запросов / транзакций, одновременно обрабатываемых системой.
Время отклика: обычно принимают среднее время отклика.
(Многие люди часто путают число параллелизма и понимание TPS)
Поняв значение трех вышеуказанных элементов, вы можете рассчитать взаимосвязь между ними:
QPS (TPS) = Количество одновременных запросов / Среднее время ответа или Количество одновременных запросов = QPS * Среднее время ответа
Типичная система входа для работы. Вы выходите на работу в 8 утра, а пользователь входит в систему входа на 30 минут с 7:30 до 8:00. В компании работает 1000 сотрудников, и среднее время входа каждого сотрудника в систему составляет 5 минут. Для расчета можно использовать следующий метод.
QPS = 1000 / (30 * 60) транзакций / сек.
Среднее время ответа = 5 * 60 секунд.
Параллелизм = QPS * Среднее время ответа = 1000 / (30 * 60) * (5 * 60) = 166,7
Пропускная способность системы обычно определяется двумя факторами: QPS (TPS) и количеством одновременных операций. Эти два значения каждой системы имеют относительное предельное значение. Под давлением доступа к сценарию приложения, пока один элемент достигает наивысшего значения системы, система Пропускная способность не увеличится. Если давление будет продолжать увеличиваться, вместо этого упадет пропускная способность системы. Причина в том, что система перегружена, а другое потребление, такое как переключение контекста, память и т. Д., Приводит к снижению производительности системы.
Факторы, определяющие время отклика системы
Время отклика системного вызова такое же, как и в плане проекта, но также существует критический путь, то есть время воздействия системы;
Критический путь состоит из операций ЦП, ввода-вывода, ответа внешней системы и т. Д.
два. Оценка производительности системы:
При проектировании системы нам необходимо учитывать влияние операций ЦП, операций ввода-вывода и факторов отклика внешней системы, а также предварительные оценки производительности системы.
В нормальных условиях, когда мы сталкиваемся с требованиями, помимо QPS и параллелизма, есть еще одно измерение: дневная PV.
Наблюдая за журналом доступа системы, обнаруживается, что в случае большого количества пользователей трафик доступа в один и тот же период времени в каждый период времени почти одинаков. Например, каждое утро в будние дни. Пока мы можем получить дневную диаграмму потока и QPS, мы можем рассчитать дневной поток.
Обычные технические приемы:
1. Найдите самые высокие TPS и дневные PV системы. Эти два элемента имеют относительно стабильную взаимосвязь (за исключением праздников и сезонных факторов).
2. С помощью стресс-теста или эмпирической оценки получается наивысшее значение TPS, а затем используется соотношение 1 для расчета максимальной суточной пропускной способности системы. Китайцы B2B и Taobao сталкиваются с разными группами клиентов. Сетевое поведение этих двух групп клиентов не применяется, и соотношение между TPS и PV отличается.
Соотношение между TPS и PV Taobao обычно составляет самый высокий TPS: PV составляет примерно 1: 11 * 3600 (эквивалентно 11 часам доступа при самом высоком TPS. Это сценарий для деталей продукта. Различные сценарии приложений будут иметь некоторые различия)
Б) B2B китайская станция
Взаимосвязь между TPS и PV B2B сильно различается в зависимости от системы и различных сценариев приложений. По приблизительным оценкам, она составляет около 1: 8 часов (данные анализа трафика для подробных данных о предложениях в 2009 году). Существует большая разница между пропорциями Wangpu и offerdetail, что может быть вызвано временной высокой долей краулеров.
В среде Taobao, если предположить, что TPS, которое мы проводим в стресс-тесте, равно 100, то ежедневная пропускная способность этой системы = 100 * 11 * 3600 = 3,96 миллиона.
Это в случае простых (один URL), некоторых страниц, на странице есть несколько запросов, фактическая пропускная способность системы еще меньше.
Независимо от того, есть ли время на обдумывание (T_think), значение TPS, полученное в результате теста, количество одновременных виртуальных пользователей (U_concurrent) и время отклика транзакции (T_response), считываемое Loadrunner, имеют следующие отношения (при стабильной работе):
TPS=U_concurrent / (T_response+T_think)。
Взаимосвязь между количеством одновременных запросов, QPS и средним временем отклика.
Основные понятия и формулы расчета тестирования производительности программного обеспечения
1. В центре внимания производительность программного обеспечения
На какую производительность стоит обратить внимание при тестировании ПО?
Мы думаем о том, какие роли задействованы в разработке, развертывании, использовании и обслуживании программного обеспечения, а затем рассматриваем, на каких аспектах производительности эти роли сосредоточены. Как инженер по тестированию производительности программного обеспечения, на чем мы должны сосредоточиться?
Для пользователей, когда они нажимают кнопку, ссылку или выдают инструкцию, до тех пор, пока система не отобразит результаты в форме, которую воспринимает пользователь, время, затраченное на этот процесс, является интуитивным впечатлением пользователя о производительности программного обеспечения. Это то, что мы называем временем отклика. Когда соответствующее время невелико, взаимодействие с пользователем хорошее. Конечно, время отклика взаимодействия с пользователем включает личные субъективные факторы и объективное время отклика. При разработке программного обеспечения нам нужно подумать, как улучшить Объедините эти две части, чтобы добиться наилучшего взаимодействия с пользователем. Например, когда пользователь запрашивает большой объем данных, мы можем отобразить первые извлеченные данные для пользователя и продолжить извлечение данных, пока пользователь их просматривает. В это время пользователь не знает, что мы делаем в фоновом режиме.
Пользователь обеспокоен соответствующим временем действия пользователя.
Во-вторых, мы рассматриваем аспекты производительности, которые требуют внимания с точки зрения администратора.
1. Соответствующее время
2. Разумно ли использование ресурсов сервера?
3. Разумно ли использование ресурсов сервера приложений и базы данных?
4. Можно ли расширить систему?
5. Какое максимальное количество пользователей может поддерживать система и каков максимальный объем бизнес-обработки в системе?
6. Где может быть узкое место в производительности системы
7. Изменение этих устройств может повысить производительность.
8. Может ли система поддерживать бизнес-доступ 7 × 24 часа?
Опять же, рассмотрим это с точки зрения разработчиков (дизайнеров).
1. Разумна ли архитектура?
2. Разумна ли конструкция базы данных?
3. Есть ли у кода проблемы с производительностью?
4. Есть ли в системе неоправданное использование памяти?
5. Есть ли в системе какой-либо необоснованный метод синхронизации потоков?
6. Существует ли в системе необоснованная конкуренция за ресурсы.
Итак, на что нам следует обратить внимание с точки зрения инженеров по тестированию производительности?
Одним словом, надо обратить внимание на все вышеперечисленные моменты производительности.
Два, несколько основных условий производительности программного обеспечения
1. Время ответа: время, необходимое для ответа на запрос.
Время передачи по сети: N1 + N2 + N3 + N4
Время обработки сервера приложений: A1 + A3
Время обработки сервера базы данных: A2
Время отклика = N1 + N2 + N3 + N4 + A1 + A3 + A2
2. Формула расчета количества одновременных пользователей.
Количество пользователей системы: количество пользователей, оцененных системой, например системой OA, общее количество пользователей, которые могут использовать систему, составляет 5000, тогда это количество является количеством пользователей системы.
Количество одновременных онлайн-пользователей: наибольшее количество одновременных онлайн-пользователей в определенном временном диапазоне.
Количество одновременных онлайн-пользователей = количество запросов в секунду RPS (пропускная способность) + количество одновременных подключений + среднее время обдумывания пользователем
Расчет среднего количества одновременных пользователей: C = nL / T
Расчет пикового количества одновременных пользователей: C ^ примерно равно C + 3 * радикал C
3. Формула расчета пропускной способности
Относится к количеству запросов пользователей, обрабатываемых системой за единицу времени.
С точки зрения бизнеса пропускную способность можно измерить в единицах измерения, таких как количество запросов в секунду, количество страниц в секунду, количество людей в день или количество обработанных транзакций в час.
С точки зрения сети пропускная способность может быть измерена в байтах в секунду.
Для интерактивных приложений индекс пропускной способности отражает нагрузку на сервер, которая может указывать на нагрузочную способность системы.
Когда нет узких мест в производительности, существует определенная связь между пропускной способностью и количеством виртуальных пользователей, которую можно рассчитать по следующей формуле: F = VU * R /
4. Счетчик производительности
Это некоторые индикаторы данных, которые описывают производительность сервера или операционной системы, например, объем используемой памяти и время процесса, которые играют роль «мониторинга и анализа» при тестировании производительности, особенно при анализе всей масштабируемости и определении новых узких мест в энергии. Очень важная роль.
Использование ресурсов: относится к использованию различных ресурсов в системе, например, коэффициент использования ЦП составляет 68%, коэффициент использования памяти составляет 55%, обычно используется «фактическое использование ресурсов / общий доступный ресурс» для формирования коэффициента использования ресурсов.
5. Формула расчета времени обдумывания.
Время обдумывания, с точки зрения бизнеса, это время относится к интервалу времени между каждым запросом, когда пользователь выполняет операцию. Чтобы смоделировать этот интервал времени при проведении тестирования новой энергии, вводится концепция времени обдумывания, чтобы сделать его более реалистичным. Для имитации действий пользователя.
В формуле пропускной способности F = VU * R / T показывает, что пропускная способность F является функцией количества VU, количества запросов, выданных каждым пользователем R, и времени T, а R можно рассчитать по времени T и времени размышлений пользователя TS. Расчет: R = T / TS
Вот общий порядок расчета времени на обдумывание:
A. Сначала подсчитайте количество одновременных пользователей в системе.
Б. Рассчитайте среднюю пропускную способность системы
F=VU * R / T R×C = VU * R / T
C. Подсчитайте среднее количество запросов, отправленных каждым пользователем.
D. Рассчитайте время обдумывания по формуле
Пропускная способность / мощность обработки
Производительность обработки также называется пропускной способностью, что означает количество клиентских запросов, обрабатываемых за единицу времени. Обычно пропускная способность измеряется количеством запросов в секунду или количеством страниц в секунду. С точки зрения бизнеса, пропускную способность также можно измерить количеством посетителей в день или просмотром страниц в день.
Одновременные онлайн-пользователи
Для веб-сайта, когда пользователь входит на главную страницу веб-сайта, он начинает выполнять различные операции на веб-сайте, включая просмотр веб-страниц, получение контента, отправку форм и т. д. Этот процесс Пользователи называются онлайн-пользователями. Если много таких пользователей посещают веб-сайт в один и тот же момент времени или в течение одного периода времени, эти пользователи все вместе называются одновременными онлайн-пользователями веб-сайта. В то же время другой уровень понимания онлайн-пользователей заключается в том, что система приложений в целом рассматривается как черный ящик, от уровня клиента пользователя до системы, сколько людей в целом ее используют. При выполнении тестирования производительности, если вы используете одновременных онлайн-пользователей, вы можете назвать это одновременной онлайн-нагрузкой.
Скрипт теста производительности
Скрипт разработан с помощью инструмента моделирования нагрузки. Скрипт представляет собой комбинацию некоторых кодов, он использует код для реализации действий пользователя в системе приложения. Например, вы посещаете домашнюю страницу веб-сайта, вводите имя пользователя и пароль и нажимаете кнопку входа в систему, чтобы войти в систему. Это двухэтапная операция, выполняемая пользователем в системе приложения. Сценарий содержит код для реализации этих двух шагов. Если вы хотите смоделировать загрузку 10 000 пользователей, 50% из этих 10 000 пользователей посещают домашнюю страницу, 20% регистрируются, 20% запрашивают и 10% просматривают определенную страницу, вам необходимо создать 5 скриптов соответственно Это сценарий доступа к домашней странице, сценарий регистрации, сценарий запроса и сценарий просмотра страниц.
сделка
Транзакция делится на два определения: бизнес-уровень и технический уровень. Транзакция бизнес-уровня относится к завершению полной бизнес-операции, такой как операция вывода и запроса. Техническая транзакция относится к системной операции от приложения к приложению или от приложения к базе данных. Общая бизнес-транзакция состоит из нескольких технических транзакций. В зависимости от сложности бизнес-транзакции и архитектуры системных приложений соотношение составляет примерно 1: 2–1: 10.
(1) В налоговой системе вы можете использовать «система обрабатывает бизнес-операции 100 000 пользователей каждый месяц», где TPS измеряется количеством компаний в месяц; (2) В налоговой системе вы также можете использовать «система обработает 40 000 бизнес-операций пользователей в течение 8 часов на седьмой день». TPS здесь измеряется количеством компаний в день; (3) В налоговой системе вы также можете использовать «Система должна обработать 3 операции транзакции по уплате налогов для 12 000 пользователей с 10:00 до 11:00 на седьмой день, то есть 36 000 операций транзакций по уплате налогов», где TPS измеряется количеством транзакций в час; (4 ) В налоговой системе вы также можете использовать «Система будет обрабатывать 3 типа транзакций по уплате налогов для 12 000 пользователей с 10:00 до 11:00 на седьмой день, то есть 36 000 операций транзакций по уплате налогов, каждая транзакция по уплате налогов». Чтобы отправить в среднем 10 HTTP-запросов от клиента к серверу, то есть 360 000 операций HTTP-запросов «, TPS здесь измеряется количеством запросов в час.
Точность тестирования производительности
После выполнения правильного анализа теста производительности получены правильные требования к тесту производительности, и инструменты тестирования производительности используются для разработки соответствующих сценариев тестирования производительности, разработки соответствующих сценариев тестирования производительности и выполнения теста производительности. Сценарий использует данные теста производительности, устанавливает соответствующее время обдумывания в сценарии тестирования производительности, устанавливает рабочие параметры в сценарии тестирования производительности и т. Д., Чтобы использовать инструменты автоматического тестирования производительности для имитации ситуации, в которой большое количество пользователей одновременно обращается к тестируемой системе в реальности. То есть, если инструмент тестирования производительности не используется должным образом, это приведет к неспособности точно достичь цели «моделирования реальных условий». Например, некоторые инженеры по тестированию производительности не знают, как использовать функцию «контрольной точки» при использовании инструментов тестирования производительности, поэтому они не могут найти серьезную проблему, заключающуюся в том, что большое количество виртуальных пользователей даже не входит в систему во время выполнения теста производительности. Они все еще думают, что тест производительности выполняется. Эффект хороший, проблем с производительностью тестируемой системы нет.
Веб-сервер и сервер приложений
С точки зрения непрофессионала, веб-сервер обслуживает страницы, чтобы браузер мог их просматривать, но сервер приложений предоставляет методы, которые может вызывать клиентское приложение. Чтобы быть точным, вы можете сказать: веб-серверы специализируются на обработке HTTP-запросов, но серверы приложений обслуживают бизнес-логику для приложений через множество протоколов. Веб-сервер (веб-сервер) Веб-сервер может обрабатывать протокол HTTP. Когда веб-сервер получает HTTP-запрос (запрос), он возвращает HTTP-ответ (ответ), например, отправляя обратно HTML-страницу. Чтобы обработать запрос (запрос), веб-сервер может ответить на статическую страницу или изображение, выполнить перенаправление страницы или делегировать создание динамического ответа некоторым другим программам, таким как CGI. Сценарий, сценарий JSP (JavaServer Pages), сервлеты, сценарий ASP (Active Server Pages), серверный JavaScript или некоторые другие серверные технологии. Независимо от их (примечание переводчика: скрипт) цели эти серверные программы обычно генерируют HTML-ответ (ответ) для просмотра браузером. Вы знаете, модель делегирования веб-сервера очень проста. Когда запрос (запрос) отправляется на веб-сервер, он просто передает запрос (запрос) программе, которая может обработать запрос (примечание переводчика: сценарий на стороне сервера). Веб-сервер предоставляет только среду, в которой программа на стороне сервера может быть выполнена, а ответ (сгенерированный программой) может быть возвращен, не выходя за рамки его функций. Серверные программы обычно имеют такие функции, как обработка транзакций, подключение к базе данных и обмен сообщениями. Хотя веб-сервер не поддерживает обработку транзакций или создание пулов соединений с базой данных, он может использовать различные стратегии для достижения отказоустойчивости и масштабируемости, такие как балансировка нагрузки и буферизация. (кеширование). Функции кластеризации (функции кластеризации) часто ошибочно принимают за просто функции, специфичные для сервера приложений. к
Сценарий 1. Веб-сервер без сервера приложений В этом сценарии веб-сервер независимо выполняет функцию интернет-магазина. Веб-сервер получает ваш запрос и затем отправляет его серверной программе, которая может его обработать. Эта программа ищет информацию о ценах из баз данных или текстовых файлов (плоский файл, примечание переводчика: плоский файл относится к небинарным файлам без специального формата, таким как свойства, файлы XML и т. Д.). После обнаружения программа на стороне сервера формулирует информацию о результатах в форме HTML, и, наконец, веб-сервер отправляет ее в ваш веб-браузер. Короче говоря, веб-сервер просто отвечает на HTML-страницы для обработки HTTP-запросов. к
Сценарий 2: веб-сервер с сервером приложений. Сценарий 2 аналогичен сценарию 1, является ли это веб-сервером или генерацией ответов (делегатов) на сценарий (Примечание переводчика: сервер (Серверная программа). Однако вы можете разместить бизнес-логику для определения цен на сервере приложений. Из-за этого изменения этот сценарий просто вызывает службу поиска на сервере приложений, вместо того, чтобы уже знать, как искать данные, а затем выражать их в качестве ответа. В это время, когда программа-скрипт генерирует HTML-ответ (ответ), можно использовать возвращенный результат службы. В этом сценарии сервер приложений обслуживает бизнес-логику для запроса информации о ценах на продукты. Эта функция (сервера) не определяет подробные сведения об отображении и о том, как клиент использует эту информацию. Вместо этого клиент и сервер приложений просто передают данные туда и обратно. Когда клиент вызывает службу поиска сервера приложений, служба просто ищет и возвращает результаты клиенту. Отделив его от HTML-кода, генерирующего ответ, логику ценообразования (поиска) можно многократно использовать в приложении. Другие клиенты, например кассовые аппараты, также могут позвонить в ту же службу, что и клерк, чтобы проверить клиента. В отличие от этого, служба поиска цен в сценарии 1 не может использоваться повторно, поскольку информация встроена в HTML-страницу.в целомВ модели сценария 2 веб-сервер обрабатывает HTTP-запросы (запросы), отвечая на HTML-страницы, в то время как сервер приложений предоставляет логику приложения, обрабатывая цены и доступность (запросы). к
Предупреждение (предостережения). Теперь веб-службы XML запутали границу между сервером приложений и веб-сервером. Отправляя полезную нагрузку XML (полезную нагрузку) на сервер, веб-сервер теперь может обрабатывать данные и ответ (ответ) в той же степени, что и предыдущий сервер приложений. Кроме того, большинство серверов приложений теперь включают в себя веб-серверы, а это означает, что веб-серверы можно рассматривать как подмножество серверов приложений. Хотя сервер приложений включает в себя функцию веб-сервера, разработчики редко развертывают сервер приложений в этом качестве (Примечание переводчика: эта функция относится как к функциям сервера приложений, так и Функция веб-сервера). Напротив, при необходимости они обычно настраивают веб-сервер независимо друг за другом с сервером приложений. Такое разделение функций помогает повысить производительность (простые веб-запросы (запросы) не повлияют на сервер приложений), раздельную конфигурацию (выделенный веб-сервер, кластеризацию и т. Д.) И предоставить лучший продукт. ВыбратьПокинуть комнату。
Узкое место в производительности
Узкое место производительности на самом деле является дефектом производительности программного обеспечения, наиболее популярным пониманием является «узкое место производительности».
(1) Узкое место производительности оборудования в основном связано с проблемами ЦП и ОЗУ. Например, во время анализа требований к программному обеспечению и эскизного проектирования было определено, что на сервере базы данных требуется 6 ЦП и 12 ГБ памяти, но в ходе теста было обнаружено, что непрерывное использование ЦП превышает 95%. В это время можно считать, что оборудование появилось. Узкое место в производительности.
(3) Узкие места в производительности приложений обычно относятся к приложениям, недавно разработанным разработчиками. Например, приложение, разработанное на Java или C и развернутое на сервере приложений для обработки запросов пользовательских транзакций. Например, разработчик разработал программу обработки платежей. В ходе тестирования было обнаружено, что программа обработки платежей может обрабатывать только параллельные платежные запросы, отправленные пользователем последовательно, и не может обрабатываться параллельно, что приводит к времени отклика обработки платежной транзакции. Очень долго, на данный момент можно считать, что в приложении есть узкое место в производительности.