Что такое rps нагрузка
Яндекс.Танк и автоматизация нагрузочного тестирования
В ходе тестирования некоторых продуктов компании Positive Technologies возникла необходимость проведения быстрых стресс-тестов одного веб-сервиса. Эти тесты должны были быть простыми и быстрыми в разработке, нетребовательными к аппаратным ресурсам и одновременно с этим давать значительную нагрузку однотипными HTTP-запросами, а также предоставлять статистические данные для анализа системы под нагрузкой.
Для их реализации мы исследовали и опробовали некоторое количество инструментов, среди которых были Apache JMeter и написанный нами на Python скрипт LogSniper, который выполнял реплей заранее подготовленных серверных логов с HTTP-запросами на цель.
От использования JMeter было решено отказаться из-за значительной сложности подготовки и проведения тестов, высоких требований к производительности нагрузочного стенда и довольно малых мощностей нагрузки, хотя эти недостатки и компенсировались высокой информативностью собираемой статистики. LogSniper был отклонен из-за малой мощности генерируемой нагрузки и здесь даже простота подготовки нагрузочных HTTP-пакетов не смогла перевесить. Другие известные инструменты нам по тем или иным причинам тоже не подошли.
В итоге мы остановились на инструменте Яндекс.Танк, о котором узнали, побывав на конференции YAC-2013 и пообщавшись со специалистами Яндекса. Этот инструмент полностью отвечал всем нашим требованиям к простоте подготовки теста и к генерируемой нагрузке.
Что это
Яндекс.Танк — инструмент для проведения нагрузочного тестирования, разрабатываемый в компании Яндекс и распространяемый по лицензии LGPL. В основе инструмента лежит высокопроизводительный асинхронный генератор нагрузки phantom: он был переделан из одноименного веб-сервера, который «научили» работать в режиме клиента. При помощи phantom можно генерировать десятки и сотни тысяч HTTP-запросов в секунду (http-requests per second, http-rps).
В процессе своей работы Танк сохраняет полученные результаты в обычных текстовых журналах, сгруппированных по директориям для отдельных тестов. Во время теста специальный модуль организует вывод результатов в консольный интерфейс в виде таблиц. Одновременно запускается локальный веб-сервер, позволяющий видеть те же самые результаты на информативных графиках. По окончании теста возможно автоматическое сохранение результатов на сервисе Loadosophia.org. Также имеется модуль загрузки результатов в хранилище Graphite.
Некоторые полезные ссылки:
Сравнение производительности двух аналогичных веб-сервисов
В ходе работы нам потребовалось сравнить характеристики двух веб-сервисов, работу которых можно примерно описать как «прозрачные HTTP-прокси, перенаправляющие входящие запросы на backend-приложение».
Общую схему работы можно изобразить следующим образом:
На стенде с Танком использовался генератор нагрузки phantom с включенным монитором производительности.
В качестве стенда web-proxy на схеме использовались два тестируемых веб-сервиса, с которых при помощи агента Танка снимались показатели производительности. Условно назовем их Эталонный веб-сервис и Испытуемый веб-сервис. Нам требовалось понять, соответствует ли производительность испытуемого веб-сервиса эталонному.
Для backend использовалось небольшое веб-приложение, запущенное под Nginx и возвращающее одну простую HTML-страничку.
Выявленные ограничения
Перед началом работ мы собрали информацию об ограничениях виртуальных стендов, на которых была построена вся тестовая инфраструктура.
Характеристики стенда backend-приложения:
25 000 http-rps, но и при нагрузке выше 25k http-rps работа стенда не была нарушена.
Стенд Танка с характеристиками 16 vCPU, 8 GB, 10 Gb/s позволил реализовать нагрузку до 300 000 http-rps.
Пропускная способность виртуальной среды ESXi, определенная с помощью Iperf, составила 8 Gb/s в одну сторону, 4 Gb/s при двухсторонней нагрузке между двумя виртуальными машинами.
Метрики и критерии сравнения
Перед началом работы для дальнейшего измерения мы определили следующие метрики каждого профиля нагрузки:
В данном случае мы решили выбрать следующие критерии для сравнения работы веб-сервисов под нагрузкой:
Тестовые HTTP-запросы
Для одного из профилей нагрузочных тестов нам требовалось создать смешанный HTTP-трафик из GET- и POST-запросов с линейным возрастанием нагрузки до 10k http-rps в течение 10 минут.
Чтобы упростить подготовку патрона для такого смешанного трафика, мы сделали скрипты, аналогичные perl-скриптам, предлагаемым на форуме.
Сбор данных и анализ результатов
После подготовки запросов мы просто запустили Танк стандартным образом и выполнили нагрузочный тест со смешанным трафиком для обоих тестируемых веб-сервисов.
Результаты для эталонного веб-сервиса
Информация веб-монитора Танка:
Информация консоли Танка:
Результаты для испытуемого веб-сервиса
Информация веб-монитора Танка:
Информация консоли Танка:
Даже судя по графикам, испытуемый сервис показывал результаты не хуже, чем эталонный. Проверив все три формально определенных выше критерия, мы в этом убедились.
Выводы
По результатам работы с Яндекс.Танком можно с полной ответственностью заявить, что этот инструмент отлично подходит в тех случаях, когда требуется быстро провести нагрузочное тестирование веб-приложений без их сложной подготовки и при этом получить множество полезных статистических данных для анализа производительности.
Кроме того, он хорошо внедряется в имеющиеся системы автоматизации. Например, для упрощения работы со стендом Танка — управления, запуска, подготовки патронов для лент, контроля за процессом тестирования и сбором результатов — мы без особых усилий написали класс-обвязку на Python, который подключается к стенду по SSH и выполняет все перечисленные действия. Затем этот класс был встроен в нашу существующую систему авто-тестирования.
Дополнительно вы можете посмотреть, как подключить и использовать высокопроизводительную систему Graphit для анализа большого числа графиков (о ней рассказывалось в одной из презентаций на конференции YAC-2013). Ее также можно приспособить для нужд нагрузочного тестирования с использованием Яндекс.Танка.
Выражаю благодарность моему коллеге Олегу Каштанову за техническую поддержку.
Как оценить ёмкость сервиса и не упасть под нагрузкой
Рано или поздно любому растущему сервису приходится оценивать свои технические возможности. Сколько посетителей мы в силах обслужить? Какова ёмкость (она же capacity) системы? Не добрались ли мы до предела и не упадём ли, если привлечём ещё несколько тысяч пользователей? Сколько дополнительных вычислительных ресурсов заложить в бюджет на следующий год, чтобы соответствовать планам роста?
Ответы можно получить аналитическим путём, адресовав вопросы опытному разработчику/DevOps/SRE/админу. Достоверность оценки зависит от огромного числа факторов: начиная с темпов наполнения системы функциональностью и графа взаимосвязей между компонентами и заканчивая временем, которое эксперт с утра провёл в пробке. Чем сложнее система — тем больше сомнений в адекватности аналитической оценки.
Меня зовут Максим Куприянов, вот уже пять лет я работаю в Яндекс.Маркете. Сегодня я расскажу читателям Хабра, как мы учились оценивать ёмкость наших сервисов и что из этого вышло.
Выходим на позицию
Структура компонентов Маркета довольно сложна, так что мы решили оценить ёмкость только самых крупных и дорогих в масштабировании сервисов. При этом ежедневное количество запросов на них должно явно зависеть от размера дневной аудитории Маркета (daily active users, DAU). Почему именно от DAU? Да потому что аналитики, строя прогнозы на месяцы и годы вперёд, всегда подсчитывают будущий размер аудитории, а мы этим приятным обстоятельством как раз и воспользуемся.
Теперь поговорим о том, без чего точно не построить объективные оценки: о метриках работы сервиса. Если число запросов на сервис зависит от DAU — значит, нам точно понадобится метрика «число запросов в секунду» (requests per second, RPS). Кроме того, чтобы оценить качество работы сервиса, нужно знать процент ошибок и времён ответа (таймингов запросов). Ошибкой будем считать ответ с HTTP-кодом от 500 и выше. Ошибки из диапазона 4xx клиентские и в нормально работающей системе обычно ничего не говорят о проблемах сервиса. Что касается таймингов, то тут у нас принято рассчитывать и хранить 80-й, 95-й, 99-й и 99,9-й перцентили времён ответа, но конкретный набор может немного отличаться от сервиса к сервису.
Итак, у нас есть метрики частоты запросов, процента ошибок и набор перцентилей времени ответа. А ещё мы знаем DAU сервиса на каждый день и на будущие периоды (в виде прогноза). Учитывая, что усреднённые паттерны поведения пользователей не слишком меняются день от дня, допустим следующее: зная RPS в наиболее активный период рабочего дня (пиковое RPS), мы можем спрогнозировать пиковое RPS на будущие периоды, при условии, что у нас есть прогноз DAU. И наоборот: если мы знаем, сколько запросов в секунду выдерживает система, не нарушая договорённости по времени ответа и проценту ошибок, то можем оценить, какой объём аудитории сможем обслужить, т. е. знаем ёмкость системы.
Отлично, мы определились с задачей: зафиксировать в виде договорённостей тайминги ответа и процент ошибок и найти максимальное RPS, которое система выдержит при этих условиях. Как будем решать?
Стреляем по мишени
Вот классический подход к решению задачи: собираем тестовый полигон, берём access-логи системы из production-окружения, делаем из них патроны и обстреливаем систему, повышая частоту запросов, пока полигон не покажет значимую деградацию по таймингам ответа и/или ошибкам. В этот момент останавливаемся и фиксируем частоту запросов (то самое RPS). Победа? Как бы не так. И вот почему:
Имитируем реальность
Общая идея такова: скопируем часть трафика с балансеров на площадку, где соберём полный аналог production-окружения в миниатюре и, регулируя объём копируемого трафика, станем искать точку деградации. Идея красивая, и мы в Маркете так делаем, чтобы протестировать новую функциональность и сравнить поведение новых версий со старыми. Мой коллега Евгений в подробностях рассказывал об этом — см. раздел о теневом кластере. Но тут тоже есть очевидные сложности:
Тестируем прямо в production
И вот мы наконец добрались до вкусного. Для каждого тестируемого компонента мы поднимаем в production отдельный экземпляр, частоту запросов на который регулируем с балансировщика с высокой точностью. В прошлый раз читатели нас спрашивали: «Хватает ли возможностей HAProxy? Не возникала ли необходимость писать что-то своё?». Так вот, это тот самый редкий случай, когда не хватило и пришлось писать.
При этом есть отдельный сервис, который пристально наблюдает за метриками нагружаемого экземпляра и, когда показатели приближаются к критическим величинам, прикрывает вентиль на балансировщике, уменьшая частоту запросов. Если же сервис работает в допустимых границах — вентиль, наоборот, открывается. Конечно, пороги таймингов и ошибок при нагрузке живого сервиса заметно более консервативны (обычно на 5–10%), чем на полигоне, ведь мы не хотим ухудшать взаимодействие с пользователями. Таким образом, нагружаемый экземпляр всегда работает на пределе возможностей. Эти показатели мы фиксируем. А дальше уже арифметика: мы знаем количество ядер сервиса под нагрузкой на каждый момент, знаем DAU за вчерашний день. Из этого считаем утилизацию, резервы по ёмкости и варианты поведения системы при отключении той или другой локации. Всё это ложится в базу, откуда строятся красивые графики. На основании этих данных при снижении ёмкости ниже заложенного порога срабатывают алерты.
Давайте посмотрим на графики
Вот так мы регулируем подачу трафика на тестируемый инстанс. Шаг может быть любым кратным 1 RPS. На графике для иллюстрации смоделирован подъём с трёхминутным интервалом: сначала от 650 до 1K RPS с шагом 50, а потом от 200 до 1K с шагом 100. Напомню, это настоящий пользовательский трафик, на который клиенты получали ответы.
Здесь показано RPS на три инстанса: один под нагрузкой и два контрольных. Для испытуемого искусственно задали верхний предел — 600 RPS. Сервис может и больше, но становится слишком неустойчивым и зависимым от внешних воздействий. Хорошо видно, что в первой половине дня запросы на сервис в среднем более тяжёлые и инстанс не может на приемлемых условиях достичь пиковой ёмкости, но ближе к вечеру всё приходит в норму. Всплески и пропуски на графике — это рестарты инстансов для выкладки релизов и прочих обновлений (все они под балансировкой, никто не пострадал). А ступенчатые корректировки RPS на испытуемом — как раз работа алгоритма, который ищет предел возможностей.
Хорошо видна частота запросов на сервис и нагрузка, которую может выдержать один инстанс.
А тут мы пересчитываем всё в проценты утилизации. На графике видно, что сервис был довольно сильно нагружен и при отключении одной из локаций возникли риски уйти за SLA. Но сейчас уже всё в порядке: в сервис добавили ресурсы, утилизация вернулась в приемлемые границы.
Таким образом, нагрузочное тестирование в production позволяет быстро оценить ёмкость системы и спрогнозировать потребление ресурсов на будущие периоды. При этом система фактически не добавляет заметных расходов и можно спокойно работать со stateful-сервисами, так как мы не порождаем новый трафик, а лишь аккуратно перераспределяем тот, что есть. Ну и напоследок: для работы, как правило, не требуется изменять код само́й подопытной системы, что позволяет тестировать даже legacy-приложения.
Рефлексируем
В Маркете эта методика работает уже не первый год, и мы можем поделиться наблюдениями и рекомендациями:
Русские Блоги
Пропускная способность системы, 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 и развернутое на сервере приложений для обработки запросов пользовательских транзакций. Например, разработчик разработал программу обработки платежей. В ходе тестирования было обнаружено, что программа обработки платежей может обрабатывать только параллельные платежные запросы, отправленные пользователем последовательно, и не может обрабатываться параллельно, что приводит к времени отклика обработки платежной транзакции. Очень долго, на данный момент можно считать, что в приложении есть узкое место в производительности.