Время отклика программы это

В настоящее время все больше компаний, использующих системы электронного документооборота (СЭД), сталкиваются с проблемами быстродействия. Ни оптимизация рабочих процессов, ни наращивание мощности используемых аппартных средств ощутимого эффекта

Довольно часто при выборе СЭД покупатели опираются на качественные оценки быстродействия или на количество будущих пользователей системы, например, «система обладает хорошим быстродействием» или «система рассчитана на одновременную работу 250 пользователей».

Такие оценки привычны и распространены, но они не дают представления о быстродействии системы в конкретной организации, потому что любые качественные оценки заведомо субъективны, а количество пользователей — далеко не единственный параметр, влияющий на быстродействие.

При выборе СЭД важно знать, как быстро будет реагировать система на действия пользователей в конкретной организации, а не что думают по этому поводу производители или как ведет себя система в других организациях с таким же или большим количеством пользователей.

I. Ghosting, Overdrive, Overshoot, Black Smearing или почему Response Time это не Input Lag

Оценить скорость доступа к данным в конкретной организации можно несколькими способами. Самый точный, но при этом и самый затратный способ — обратиться в специализированный центр, занимающийся тестированием программных продуктов. Такой способ хорошо использовать на последнем этапе выбора СЭД, в качестве окончательного подтверждения сделанного выбора.

На начальных этапах выбора СЭД, когда рассматривается множество систем, можно использовать другой, достаточно эффективный, но значительно менее затратный способ — сравнительный анализ. Он включает в себя три этапа: расчет предполагаемой нагрузки на систему в конкретной организации, запрос данных о работе системы у производителя и сравнение рассчитанной нагрузки с полученными от производителя данными.

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

Параметры быстродействия СЭД

Потенциальным покупателям СЭД важно знать, насколько быстро система будет реагировать на действия пользователей. Сколько времени будет проходить с момента выбора пользователем пункта меню или нажатия на кнопку до получения результата?

Для информационных систем такое время называют временем отклика, а общую совокупность времен отклика на базовые действия пользователей — быстродействием системы.

Быстродействие называют хорошим, если время отклика системы на типовые действия сравнимо со временем отклика других, привычных для пользователей программных продуктов.

Если бы время отклика системы на каждое действие было постоянным, то оценки «хорошее быстродействие» было бы вполне достаточно. Уточнив у производителя список рассматриваемых типовых операций и время отклика для каждой из них, вопрос о быстродействии можно было бы считать решенным. Но время отклика — величина переменная. Она очень зависит от того, на каких аппаратных средствах выполняется действие и сколько других действий в системе выполняется в то же время.

Время отклика монитора: что это и на что влияет?

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

Прежде всего — клиентские приложения, в которых работают пользователи системы. В роли таких приложений могут выступать веб-браузеры или специальные программы, являющиеся частью СЭД. В первом случае клиентское приложение называют «тонким», во втором — «толстым».

Далее, хранилище данных — физическое хранилище всей информации системы. Это могут быть базы данных или файловые системы.

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

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

Время отклика системы складывается из времени работы каждого из участвующих в процессе компьютеров и времени передачи данных между ними. И то и другое время зависит от технических характеристик используемых аппаратных средств и от нагрузки на эти средства в момент доступа к данным.

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

Время передачи данных зависит от того, какой объем информации может быть передан по каналу за единицу времени (техническая характеристика) и сколько таких объемов надо передать (нагрузка).

Нагрузка на систему, в свою очередь, определяется характером выполняемых действий и объемом данных системы, общим и нужным для выполнения конкретного действия. Например, поиск документа в базе данных объемом 20 Мбайт может происходить значительно быстрее, чем поиск документа при прочих равных условиях, но в базе данных объемом 100 Гбайт.

Таким образом, на быстродействие системы влияют архитектура системы, характеристики используемых аппаратных средств, а также нагрузка и объем данных системы. Индивидуальными для каждой организации являются нагрузка и объем данных системы, и именно их рекомендуется рассчитывать для сравнительного анализа.

Рекомендуемые архитектуру и аппаратные средства следует запрашивать у производителя СЭД с учетом предполагаемой нагрузки и объемов данных в конкретной организации.

Верные способы обмануться в оценках

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

Например, вы слышите от производителя: «Система показывает высокое быстродействие при работе двухсот пользователей», и на основании этого делаете вполне логичный, с теоретической точки зрения, вывод, что в организациях с таким же или меньшим количеством пользователей система будет работать достаточно быстро. Но на практике может быть совсем не так.

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

Во-вторых, могло получиться так, что 200 заявленных пользователей в процессе тестирования выполняли одну и ту же операцию с пятиминутным интервалом, а это в большинстве организаций соответствует работе вовсе не 200 пользователей, а максимум — 20. Действительно, при средней интесивности работы 200 пользователей выполняют от 300 (создание документа) до 1500 (просмотр документа) различных операций в день. А при пятиминутном интервале за восемь часов будет выполнено всего около 100 операций.

В-третьих, 200 пользователей могли работать с базой данных документов объемом в 20 Мбайт, что при средних темпах роста базы данных с нулевого объема не соответствует даже первому дню «реальной» работы 200 пользователей в системе.

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

В-пятых, система могла показать приведенные результаты на восьмипроцессорном сервере, что для 200 пользователей явно дороговато.

Подобных подводных камней встречается очень много и учесть их все без обращения к точным оценкам быстродействия СЭД практически невозможно.

К точным оценкам относятся список типовых действий со временем отклика для каждого из них и условия, при которых система показывает указанное время отклика: нагрузка, объем данных и аппаратные средства.

Таблицы для расчета нагрузки на систему

Расчет нагрузки и объемов данных системы удобно производить, исходя из предполагаемого количества пользователей системы. Для этого нужны две таблицы: таблица интенсивности работы пользователей — сколько и каких операций в день выполняет один пользователь — и таблица распределения документов в базе данных — типы документов в зависимости от их среднего размера и процентное соотношение таких документов в базе данных .

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

Например, по данным анализа проектов внедрения системы Directum в организациях разного профиля (производственные и проектные организации, предприятия нефтяной отрасли), в работе пользователей наблюдаются определенные закономерности.

Число одновременно работающих в системе пользователей в среднем составляет 30% от общего количества пользователей. Например, если в организации планируется автоматизировать работу 1500 сотрудников, то в системе одновременно будут работать около 500 пользователей.

По степени активности пользователи делятся на три группы: высокоактивные, среднеактивные и низкоактивные.

Пользователи с высокой активностью практически все свое рабочее время проводят в системе, постоянно создавая, изменяя, просматривая документы, запуская на выполнение автоматизированные бизнес-процессы и т.д. Как правило, к этой категории относятся секретари, работники канцелярии, руководители отделов. На их долю приходится 6% от общего количества одновременно работающих пользователей и 25% всех выполняемых операций.

Пользователи со средней активностью достаточно активно работают в системе, проводя в ней значительную часть рабочего времени, но их активность ниже, чем у пользователей первой группы. На этих сотрудников приходится 30% от количества одновременно работающих пользователей (лицензий) и 30% всех выполняемых операций.

Пользователи с низкой активностью используют систему эпизодически — несколько раз в день обращаются к ней, проверяют назначенные им поручения и выданные задания, при необходимости просматривают и корректируют документы. На их долю приходится 64% от количества одновременно работающих пользователей и 45% всех выполняемых операций.

Таким образом, из 500 одновременно работающих пользователей 30 проявляют высокую активность, 150 — среднюю, а остальные 320 пользователей — низкую.

Пользователи каждой группы за день выполняют определенное количество базовых операций (см.табл. 1; количество операций приведено в расчете на одного пользователя каждой группы).

Например, 500 одновременно работающих пользователей за день в системе в среднем создают около 850 документов, из этого колическтва 600 документов создают пользователи с высокой активностью, 150 — со средней, а остальные пользователи — с низкой активностью.

В течение дня во всех группах наблюдаются пики и спады активности пользователей (см.табл. 2).

Из 850 создаваемых за день документов 340 создаются в послеобеденные часы.

Объемы и типы создаваемых документов в среднем распределяются так, как показано в табл. 3.

Например, из 850 документов 680 будут офисными, а 170 графическими. Общий объем создаваемых за день документов составит 680 Mб.

В соотвествии с такими средними данными интенсивность работы 300 пользователей показана в табл. 4.

Объем документов в базе данных по прошествии двух лет можно вычислить по данным таблиц 3 и 4.

Это, например, значит, следующее: чтобы оценить скорость работы системы для организации с 300 действующими пользователями, необходимо сымитировать выполнение операций в этой системе в соответствии с данными таблицы 5 на базе данных порядка 70 Гбайт.

Рекомендации по работе с данными от производителя

При выборе СЭД с точки зрения быстродействия у производителя рекомендуется запрашивать список типовых действий со временем отклика для каждого из них, интенсивность выполнения операций, объем данных и используемые аппаратные средства.

Этих значений вполне достаточно для того, чтобы сделать вывод о том, подходит ли система организации. Список типовых операций можно сравнивать с приведенным ниже списком самых основных операций (см.табл. 6), возникающих при использовании системы электронного документооборота (список операций для конкретной системы должен быть не короче, а длиннее, чем приведенный).

Стоимость аппаратных средств должна быть приемлемой для организации. Здесь сложно подбирать какие-либо эталонные характеристики. Самый простой и надежный способ — узнать стоимость требуемых аппаратных средств и решить, насколько эта сумма вписывается в общий бюджет внедрения системы в организации.

Интенсивность выполнения операций и объем данных следует сравнивать с рассчитанными для организации данными. Они должны быть того же или большего порядка, чем требуется организации. Если интенсивность работы или объем базы данных оказываются хотя бы на порядок ниже рассчитанных для организации, то использовать приведенные данные для оценки скорости работы системы в конкретной организации нельзя. В вопросе быстродействия можно полагаться только на экспериментально полученные данные, но не на те, которые получены путем выявления каких-либо закономерностей.

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

Практически у каждой СЭД есть так называемый порог интенсивности работы, за которым она перестает работать, независимо от используемых аппаратных средств. И чем крупнее компания, тем выше вероятность, что этот порог будет достигнут.

В целом вопрос об оценке быстродействия СЭД наиболее остро стоит именно для крупных организаций. На рынке немало систем, которые с точки зрения быстродействия подходят практически любым мелким и средним предприятиям. Порог их интенсивности обычно определяется работой одной или нескольких сотен пользователей.

Но современные требования к СЭД таковы, что системы для крупных компаний должны обеспечивать высокое быстродействие уже не 200—300 пользователей, как это было несколько лет назад, а 1000—1500 на каждом сервере. И это ничуть не завышенные требования. Уже сейчас в России есть организации, в которых количество автоматизированных пользователей системы электронного документооборота приближается к этим значениям, и со временем таких организаций будет все больше.

Именно поэтому уже сегодня качественных оценок быстродействия оказывается недостаточно и всем, кто выбирает СЭД для крупной компании, нужны точные оценки быстродействия, хотя раньше ими занимались только специалисты.

Источник: www.osp.ru

5 типов показателей времени отклика и способы их измерения

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

Что такое тестирование времени отклика?

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

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

Программы для Windows, мобильные приложения, игры — ВСЁ БЕСПЛАТНО, в нашем закрытом телеграмм канале — Подписывайтесь:)

Как измерить время отклика

Вот пять простых шагов для измерения времени отклика в приложении или на веб-сайте:

1. Определите свои параметры

Определите параметры вашего теста. Например, если вы тестируете время отклика веб-сайта, определите факторы веб-подключения и скорость загрузки или выгрузки, а также среднее время отклика других сайтов в той же сети. Если вы измеряете время отклика приложения, вы можете определить, как может выглядеть быстрое и медленное время отклика. Вы можете считать полсекунды медленным временем отклика, если другие приложения загружаются быстрее. Важно определить параметры вашего теста, чтобы вы знали, что измеряете, и создали элемент управления для своих переменных.

В эксперименте контрольная группа является неизменной метрикой для сравнения ваших результатов. Ваши переменные — это то, что вы можете изменить или что может измениться в ходе эксперимента. Например, среднее время отклика вашего приложения может выступать в качестве элемента управления во время этого теста. Различные скорости сети и подключения могут действовать как переменные для проверки контроля.

2. Проведите тест времени отклика

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

3. Запишите свои результаты

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

4. Определите ошибки или успехи

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

*Обратите внимание, что компания Indeed не связана ни с одной из компаний или продуктов, упомянутых выше.

5 типов показателей времени отклика

Вот 5 типов показателей времени отклика, которые вы можете измерить:

1. Запросов в секунду

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

2. Входящие и исходящие данные

Этот показатель отслеживает размер каждого пакета запросов к серверу и количество ответов, создаваемых сервером или приложением. Обычно разработчики и администраторы измеряют это как отношение. Например, если у вас 100 запросов к серверу и только 10 ответов, у вас соотношение 10:1. По мере увеличения трафика сервера разработчикам может потребоваться увеличить порог для запросов и выходных данных сервера, чтобы гарантировать отсутствие пауз или задержек во времени ответа.

3. Среднее время отклика

Среднее время отклика (ART) — это измерение количества времени, которое требуется серверу или приложению для ответа на все входные данные и запросы. Меньшее среднее время отклика обычно означает более высокую производительность, поскольку серверу или приложению требуется меньше времени для ответа на новые запросы. Однако метрика ART иногда может давать искаженные результаты, если в ней присутствуют высокие выбросы. Например, если сервер имеет более высокое время отклика в часы пик, эти числа могут привести к более высокому среднему значению и заставить сервер или приложение работать медленнее.

4. Пиковое время отклика

Системные администраторы обычно измеряют пиковое время отклика наряду со средним временем отклика для более полного и точного измерения времени отклика сервера. Пиковое время отклика измеряет максимальное время отклика для сервера или приложения или выбросы, упомянутые в разделе ART. Эти выбросы помогают системным администраторам определить, какие максимальные значения могут замедлить время отклика, и учесть эти выбросы при измерении ART.

5. Использование оборудования

Эта метрика измеряет, сколько аппаратных вычислительных мощностей используют запросы и время отклика. Например, вы можете измерить объем ОЗУ или оперативной памяти, которую сервер использует в пиковое время отклика, чтобы определить, соответствует ли оборудование сервера требованиям для выполнения пиковых запросов. Этот показатель помогает администраторам определить необходимость модернизации оборудования и измеряет жизнеспособность существующих аппаратных систем.

Источник: buom.ru

Тестирование времени отклика

ВРЕМЯ ОТВЕТА НА ВРЕМЯ измеряет время, необходимое одному системному узлу для ответа на запрос другого. Это время, которое требуется системе для получения определенного ввода, пока процесс не закончится. Например, у вас есть API, и вы хотите точно знать, сколько времени требуется для его выполнения и возврата данных в JSON. Время отклика измеряет ответ сервера на каждую транзакцию или запрос.

Время ответа начинается, когда пользователь отправляет запрос, и заканчивается в тот момент, когда приложение заявляет, что запрос завершен.

В этом уроке вы узнаете

• Что такое тестирование времени отклика?
• Как измерить время отклика?
• Типы ответных метрик
• Три важных значения времени отклика
• Инструменты тестирования времени отклика

Как измерить время отклика?

Время отклика измеряется с помощью инструмента тестирования, окружая важный бизнес-процесс транзакциями Start и End. Бизнес-процесс может быть действием или набором действий, которые пользователь выполняет в приложении для выполнения бизнес-задачи. В качестве примера можно привести вход в приложение или покупку книги на Amazon.com.

Для того же процесса ответ будет немного отличаться от инструмента к инструменту. Вот почему

• Метод расчета метрик, собранных каждым инструментом
• Инструменты Имитируют скорость загрузки и захвата, которые могут изменить время отклика.
• Дополнительные элементы, записанные при мониторинге пользовательских нагрузок
• Вычислительные показатели, собранные каждым инструментом, увеличивают время отклика из-за высокого потребления ресурсов.
• Архитектура двух инструментов может отличаться

Типы ответных метрик:

Метрики времени отклика объяснение

Среднее время отклика	Среднее время ответа – это среднее время, затрачиваемое на каждый запрос в оба конца. Среднее время отклика включает время загрузки HTML, CSS, XML, изображений, файлов JavaScript и т. Д. Поэтому на среднее значение влияют медленные компоненты в системе.
Пиковое время отклика	Пиковое время отклика помогает нам находить потенциально проблемные компоненты. Это помогает нам находить все нарушения на веб-сайте или в системе, где определенный запрос обрабатывается неправильно. Например, может быть выполнен большой запрос к базе данных, который может повлиять на время ответа. Этот запрос не позволяет загрузить страницу в нужное время.
Частота ошибок	Коэффициент ошибок – это математический расчет, который отображает процент проблемных запросов по отношению ко всем запросам. Этот процент учитывает все коды состояния HTTP, отображающие ошибку на сервере. Он также считает запросы, которые истекли.

Три важных значения времени отклика:

Тестирование времени отклика имеет две наиболее важные характеристики:

• Среднее время отклика
• Максимальное время отклика.

Он показывает, как долго пользователю нужно ждать, пока сервер ответит на его запрос.

Ниже приведены ключевые значения времени ответа.

Время отклика Значение

0,1 секунды	Это наиболее предпочтительное время ответа. Если время отклика составляет 0,1, пользователи всегда чувствуют, что приложение или система реагируют мгновенно, и не испытывают никаких помех.
1,0 секунды	Он определяется как максимальный предел приемлемого времени ответа. Пользователи вряд ли почувствуют какое-либо прерывание, хотя могут испытывать некоторую задержку. Время отклика более 1 секунды может прервать взаимодействие с пользователем.
10 секунд	Это максимальный предел, после которого время отклика выходит за допустимый предел. Однако в настоящее время, если время ответа превышает 6 секунд, пользователь покинет этот сайт или выйдет из приложения.

Как правило, время отклика должно быть максимально быстрым в интервале от 0,1 до 1 секунды. Тем не менее, люди могут адаптировать более медленное время отклика, но они никогда не будут довольны временем отклика, превышающим 2 секунды. Чем меньше время отклика, тем лучше удовлетворение клиента, меньшие затраты, более высокое удовлетворение клиента.

Инструменты тестирования времени отклика:

Есть много инструментов тестирования времени отклика, доступных на рынке. Три самых известных имени:

1) JMeter:

Jmeter может использоваться для тестирования нагрузки и производительности целевого приложения.

2) Загрузочный Бегун:

Load Runner – продукт нагрузочного тестирования, разработанный Microfocus. Инструмент тестирования ответов LoadRunner работает по принципу симуляции виртуальных пользователей на предметном приложении.

3) AEM:

Adobe Experience Manage, который вскоре известен как AEM, является еще одним эффективным инструментом для тестирования времени отклика. Это позволяет проверять проблемные запросы, запросы и сообщения об ошибках.

Вывод:

• Время ответа относится ко времени, которое требуется одному системному узлу для ответа на запрос другого.
• Среднее время ответа – это среднее время, затрачиваемое на каждый запрос в оба конца
• Пиковое время отклика помогает нам определить, какие компоненты потенциально проблематичны.
• Коэффициент ошибок – это математический расчет, который отображает процент проблемных запросов.
• Три критических значения времени отклика: 0,1 секунды, 1,0 секунды и 10 секунд
• Три наиболее часто используемых инструмента для тестирования времени отклика – это Jmeter, LoadRunner и AEM.

Источник: coderlessons.com