Changes

Профили нагрузки и измеряемые показатели

Возможно использовать варианты следующих профилей нагрузки:

  1. Один пользователь в системе. Может быть проведен с целью определения базовых показателей работы системы без нагрузкии и использоваться для сравнения.
  2. Штатный режим работы. Одновременная работа в системе максимального требуемого числа пользователей.
  3. Пиковая нагрузка. Скачкообразное увеличение нагрузки с кратковременным превышением максимального требуемого числа пользователей.
  4. Равномерное увеличение нагрузки. Имитация постепенного увеличения количества подключений с превышением максимального требуемого числа пользователей.

При нагрузочном тестировании серверов можно измерять следующие показатели.
Измеряемые при помощи JMeter:

  1. Среднее время прохождения набора тестов – время, в течение которого проходили отобранные тесты.
  2. Число операций – количество операций выполненных сервером, фактически это количество принятых от JMeter и обработанных пакетов данных.
  3. Число потоков – число открытых JMeter потоков при подключении к серверу, фактически это количество подключившихся пользователей.
  4. Среднее время доступа к данным – время, в течение которого JMeter получает отклик от сервера web-приложения на отправленный запрос и начинает принимать ответные данные. Фактически это время ожидания пользователем ответных результатов от web-приложения на свои запросы.
  5. 90-й процентиль времени доступа к данным – это такое значение времени доступа в мс., что при распределении времени доступа по возрастанию для всех принятых данных, 90% времени доступа попадает ниже этого значения. Таким образом, время доступа к «большинству» загружаемых при проведении тестов данных находится ниже 90-го процентиля.
  6. Максимальная общая загрузка процессоров – максимальная общая загруженность процессоров сервера во время выполнения группы тестов, %.
  7. Максимальная общая загрузка памяти – максимальная общая загруженность памяти сервера во время выполнения группы тестов, Мб.
  8. Ошибки подключения (отказы) – отношение числа успешных, выполненных запросов, к числу отказов в обработке запросов, %.

Измеряемые при помощи serverAgent, установленного на тестируемом сервере:

  1. Загрузка процессора (CPU) – график загруженности процессоров сервера (Combined CPU usage) во время выполнения теста, %.
  2. Загрузка памяти (Memory) – график загруженности оперативной памяти сервера (Combined CPU usage) во время выполнения теста, Мб.
  3. Загрузка файла подкачки (Swap) – график загруженности системного файла подкачки сервера (Number of pages/sec) во время выполнения теста, страниц/сек.
  4. Загрузка дисковой подсистемы (Disks I/O) – график загруженности жесткого диска сервера (Number of disks access/sec) во время выполнения теста, кол во обращений/сек.
  5. Загрузка сети (Networks I/O) – график загруженности сетевого адаптера сервера (Number of Kbytes/sec) во время выполнения теста, Кб/сек.

Измеряемые при помощи Monitor Results, который использует данные Busy Time, Max Time, Busy Thread, Max Thread, Used Memory, Total Memory, Max Memory, полученные от сервисной странички Tomcat:

  1. Относительный показатель производительности «Здоровье» (Health) – динамика изменения параметра Health во время выполнения теста, который показывает отношение текущего времени обработки операций к максимальному, Busy Time / Max Time, %.
  2. Относительный показатель производительности «Загрузка» (Load) – динамика изменения параметра Load во время выполнения теста,  который который вычисляется по формуле: 50*(Busy Time / Max Time) + 50*(Used Memory / Max Memory), %.
  3. Относительный показатель производительности «Память» (Memory) – динамика изменения параметра Memory во время выполнения теста, который показывает отношение используемой памяти к выделенной Tomcat (Used Memory / Total Memory), %.
  4. Относительный показатель производительности «Доступность подключений» (Thread) – динамика изменения параметра Thread во время выполнения теста, который показывает отношение текущего количества занятых потоков к максимальному, Busy Thread / Max Thread, %.

Используя средства СУБД, дополнительно для серверов БД можно измерять показатели:

  1. Интенсивность SQL-запросов (операции SELECT, INSERT, UPDATE, DELETE) в единицу времени, запросов/сек.
  2. Текущее количество открытых подключений, кол-во.
  3. Задержка репликации, мс.
  4. Частота обращения к кешу БД, кол-во обращений/сек.

Используя программы профилировщики и сборщики статистики на прикладном уровне можно измерять показатели:

  1. Генерирование страниц приложения, сек.
  2. Статистика обращения к страницам.

How to use this image

Environment variables

Variable Description Default value
Java runtime options to specify JVM garbage collection algorithm
Java runtime options to generate GC verbose file
Java runtime options for memory management used when JMeter is started
Java runtime options to specify used language
Java runtime options used when JMeter is started
Optional java args, e.g. -Dprop=val
Set the jmeter user’s group id inside the container
Set the jmeter user’s id inside the container

Running clients and servers

Runner an interactive dockerized client in non-GUI mode
Runner a detached dockerized client in non-GUI mode

Running servers

Running a server on 192.168.1.1 with default RMI port (1099) and SSL for RMI disabled
Running a server on 192.168.1.1 with specified RMI port (1098) and SSL for RMI disabled

Running clients in distributed tesing mode

Running a client in non-GUI mode with SSL for RMI disabled, connecting to a remote server on 192.168.1.1 with default RMI port (1099)

with docker

without docker

Running a dockerized client in non-GUI mode with SSL for RMI disabled, connecting to a remote server on 192.168.1.1 with specfied RMI port (1098)

with docker

without docker

Running a dockerized client in non-GUI mode with SSL for RMI disabled, connecting to the two remote servers on 192.168.1.1

with docker

without docker

Replace by your client container id or name.

or

On Linux

On macOS

Install Quartz
  • Activate the option ‘Allow connections from network clients’ in XQuartz settings
  • Quit & restart XQuartz (to activate the setting)
Run Interactive UI
# allow access from localhost
xhost + 127.0.0.1

docker pull egaillardon/jmeter-plugins
docker run -e DISPLAY=host.docker.internal:0 --interactive --tty --rm egaillardon/jmeter-plugins jmeter.sh

3.2.2 Logic Controllers¶

Logic Controllers let you customize the logic that JMeter uses to
decide when to send requests.
Logic Controllers can change the order of requests coming from their
child elements. They can modify the requests themselves, cause JMeter to repeat
requests, etc.

To understand the effect of Logic Controllers on a test plan, consider the
following test tree:

  • Test Plan
    • Thread Group
      • Once Only Controller

        Login Request (an HTTP Request)

      • Load Search Page (HTTP Sampler)
      • Interleave Controller
        • Search «A» (HTTP Sampler)
        • Search «B» (HTTP Sampler)
        • HTTP default request (Configuration Element)
      • HTTP default request (Configuration Element)
      • Cookie Manager (Configuration Element)

The first thing about this test is that the login request will be executed only
the first time through. Subsequent iterations will skip it. This is due to the
effects of the .

After the login, the next Sampler loads the search page (imagine a
web application where the user logs in, and then goes to a search page to do a search). This
is just a simple request, not filtered through any Logic Controller.

After loading the search page, we want to do a search. Actually, we want to do
two different searches. However, we want to re-load the search page itself between
each search. We could do this by having 4 simple HTTP request elements (load search,
search «A», load search, search «B»). Instead, we use the which passes on one child request each time through the test. It keeps the
ordering (i.e. it doesn’t pass one on at random, but «remembers» its place) of its
child elements. Interleaving 2 child requests may be overkill, but there could easily have
been 8, or 20 child requests.

Note the that
belongs to the Interleave Controller. Imagine that «Search A» and «Search B» share
the same PATH info (an HTTP request specification includes domain, port, method, protocol,
path, and arguments, plus other optional items). This makes sense — both are search requests,
hitting the same back-end search engine (a servlet or cgi-script, let’s say). Rather than
configure both HTTP Samplers with the same information in their PATH field, we
can abstract that information out to a single Configuration Element. When the Interleave
Controller «passes on» requests from «Search A» or «Search B», it will fill in the blanks with
values from the HTTP default request Configuration Element. So, we leave the PATH field
blank for those requests, and put that information into the Configuration Element. In this
case, this is a minor benefit at best, but it demonstrates the feature.

The next element in the tree is another HTTP default request, this time added to the
Thread Group itself. The Thread Group has a built-in Logic Controller, and thus, it uses
this Configuration Element exactly as described above. It fills in the blanks of any
Request that passes through. It is extremely useful in web testing to leave the DOMAIN
field blank in all your HTTP Sampler elements, and instead, put that information
into an HTTP default request element, added to the Thread Group. By doing so, you can
test your application on a different server simply by changing one field in your Test Plan.
Otherwise, you’d have to edit each and every Sampler.

The last element is a . A Cookie Manager should be added to all web tests — otherwise JMeter will
ignore cookies. By adding it at the Thread Group level, we ensure that all HTTP requests
will share the same cookies.

14.2.4 Export settings¶

Each property describing an exporter configuration must be
prefixed with

jmeter.reportgenerator.exporter

14.2.4.1 General properties

All exporters support these properties:

Parameters

Attribute
Description
Required

classname

The fully qualified class name of the exporter

The class of the exporter must implement
org.apache.jmeter.report.dashboard.DataExporter
.

Yes

filters_only_sample_series

Defines whether series_filter (see below)
apply only on sample series.
Default: true

No

series_filter
Sets the filter
of series. An empty value deactivates the filtering.
If not empty, regex should end with (-success|-failure)?$

Format: regular expression.
Default: «»

No

show_controllers_only

Defines whether only controller series are shown.
Default: false

No

14.2.4.2 Specific properties

Specific exporter properties must use the prefix

jmeter.reportgenerator.exporter.<exporter_id>.property

Parameters

Attribute
Description
Required

output_dir

Sets the destination directory for generated html pages.
Default: report-output

No

template_dir

Sets the source directory of template files from
which the html pages are generated.
Default: report-template

No

14.2.4.3 Graph properties

Graph properties allow exporters to overwrite some graph data.

They must use the prefix:

jmeter.reportgenerator.exporter.<exporter_id>.graph_options.<graph_id>

Parameters

Attribute
Description
Required

minX
Sets the minimum
abscissa for the graph.
No

maxX
Sets the maximum
abscissa for the graph.
No

minY
Sets the minimum
ordinate for the graph.
No

maxY
Sets the maximum
ordinate for the graph.
No

27.3 Usage¶

Here is a short step-by-step.

  1. Write your JUnit test and jar the classes
  2. Copy and paste the jar files into jmeter/lib/junit directory
  3. Start JMeter
  4. Select Test Plan
  5. Right click
    Add → Thread Group
  6. Select Thread Group
  7. Right click
    Add → Sampler → JUnit Request
  8. Enter my unit test in the name
  9. Enter the package of your JUnit test
  10. Select the class you want to test
  11. Select a method to test
  12. Enter test successful in success message
  13. Enter 1000 in success code
  14. Enter test failed in failure message
  15. Enter 0001 in failure code
  16. Select the Thread Group
  17. Right click
    Add → Listener → View Results Tree

One benefit of the JUnit sampler is it allows the user to select any method from a variety
of unit tests to create a test plan. This should reduce the amount of code an user needs to
write to create a variety of test scenarios. From a basic set of test methods, different
sequences and tests can be created using JMeter’s GUI.

For example:

Test Plan1

TestCase1.testImportCustomer
TestCase2.testUpdateRandomCustomer
TestCase1.testSelect100
TestCase2.testUpdateOrder
TestCase1.testSelect1000

TestPlan2

Cryptographic Software Notice

The U.S. Government Department of Commerce, Bureau of Industry and
Security (BIS), has classified this software as Export Commodity
Control Number (ECCN) 5D002.C.1, which includes information security
software using or performing cryptographic functions with asymmetric
algorithms. The form and manner of this Apache Software Foundation
distribution makes it eligible for export under the License Exception
ENC Technology Software Unrestricted (TSU) exception (see the BIS
Export Administration Regulations, Section 740.13) for both object
code and source code.

The following provides more details on the included software that
may be subject to export controls on cryptographic software:

Apache JMeter interfaces with the
Java Secure Socket Extension (JSSE) API to provide

HTTPS support

Apache JMeter interfaces (via Apache HttpClient4) with the
Java Cryptography Extension (JCE) API to provide

NTLM authentication

Apache JMeter does not include any implementation of JSSE or JCE.

CI

Tools & Plugins

  • JMeter Ant Task — Ant task to automate running JMeter test plans.
  • JMeter Maven Plugin — Maven plugin that provides the ability to run JMeter tests as part of the build.
  • TeamCity Performance Tests Analysis Plugin — TeamCity plugin to organize simplest performance testing in CI (no updates more).
  • Sonar JMeter Plugin — Plugin to collect JMeter performance tests results and display in Sonar dashboard (deprecated).
  • PerfAction for JMeter — GitHub Action to run performance tests using Apache JMeter and its plugins.

Tutorials & Demo

  • Jenkins
    • CI with Jenkins, Git, Maven, Grunt, and JMeter
    • How to automate JMeter tests with Maven and Jenkins:
    • JMeter Continuous Performance Testing (JMeter + Ant + Jenkins):
  • Bamboo
  • TeamCity
  • CircleCI
  • SonarQube

3.12 Using Variables to parameterise tests¶

Variables don’t have to vary — they can be defined once, and if left alone, will not change value.
So you can use them as short-hand for expressions that appear frequently in a test plan.
Or for items which are constant during a run, but which may vary between runs.
For example, the name of a host, or the number of threads in a thread group.

When deciding how to structure a Test Plan,
make a note of which items are constant for the run, but which may change between runs.
Decide on some variable names for these —
perhaps use a naming convention such as prefixing them with C_ or K_ or using uppercase only
to distinguish them from variables that need to change during the test.
Also consider which items need to be local to a thread —
for example counters or values extracted with the Regular Expression Post-Processor.
You may wish to use a different naming convention for these.

For example, you might define the following on the Test Plan:

HOST             www.example.com
THREADS          10
LOOPS            20

${HOST}${THREADS}HOST

HOST             ${__P(host,www.example.com)}
THREADS          ${__P(threads,10)}
LOOPS            ${__P(loops,20)}
jmeter … -Jhost=www3.example.org -Jloops=13

29.6 Building JMeter¶

JMeter uses Gradle to compile and build the distribution. JMeter has
several tasks defined, which make it easier for developers to build the complete project.
For those unfamiliar with Gradle, it’s a build tool similar to make on Unix.
A list of the Gradle tasks with a short description is provided
in gradle.md, which can be found
in the root source directory.

Here are some example commands.

./gradlew runGui
Build and start JMeter GUI
./gradlew createDist
Build project and copy relevant jar files to ./lib folder
./gradlew :src:dist:previewSite
Creates preview of a site to ./build/docs/site

Отчёты WebPageTest.org

sytekey webpagetest.org Raw page data (.csv) Raw object data (.csv) HTTP Archive (.har)
github.com 160819_VF_FM8 github.com.summary.csv github.com.details.csv github.com.har
google.ru 160819_C9_FQD google.ru.summary.csv google.ru.details.csv google.ru.har
habrahabr.ru 160819_8N_FRB habrahabr.ru.summary.csv habrahabr.ru.details.csv habrahabr.ru.har
jmeter.apache.org 160819_CG_FSM jmeter.apache.org.summary.csv jmeter.apache.org.details.csv jmeter.apache.org.har
linkedin.com 160819_K2_FY1 linkedin.com.summary.csv linkedin.com.details.csv linkedin.com.har
mos.ru 160819_91_G0F mos.ru.summary.csv mos.ru.details.csv mos.ru.har
stackoverflow.com 160819_S0_G18 stackoverflow.com.summary.csv stackoverflow.com.details.csv stackoverflow.com.har
yandex.ru 160819_MR_G1R yandex.ru.summary.csv yandex.ru.details.csv yandex.ru.har

Document CompleteFully Loaded

User Pages

  • JMeter FAQ
  • A step by step guide to creating regular expressions
  • JMeter and HTTPS
  • JMeterAndOperatingSystemsTested — List of operating system tested with JMeter
  • How to decode encoded/escaped URLs
  • Debugging problems when recording with the JMeter Proxy
  • Tutorials and How-to articles
    • JMeterTesting ASPNETViewState
    • JSF test with SUN implementation — Testing a SUN RI JSF Application with JMeter
    • JMeter and Amazon — Issues with load testing applications hosted in Amazon’s cloud
    • Controlling Bandwidth in JMeter to simulate different networks — Examples of httpclient.socket.http.cps to simulate network bandwidth
  • General Articles on Performance testing etc.
    • How many threads does JMeter support?
    • JMeterAutomatedRemoteTesting — notes on remote testing and parametrisation
  • Why does JMeter get different results from my browser?
  • Some error messages and possible causes
  • It does not work! Fault Reporting
  • JtlFiles — information on JTL files
  • RegularExpressions — examples etc
  • LogAnalysis using Perl and Excel etc
  • NetworkSniffer — tools to capture HTTP Requests
  • MonitoringServers — tools to monitor servers
  • Benchmarking MySQL with JMeter and MySQL
  • JMeter Shortcuts — Current and proposed changes
  • JMeter Performance evolution accross versions — A performance comparison of JMeter versions starting from 2.5.1
  • Socket closed increase since JMeter 2.10

Автоматизация обработки логов

Apache.JMeterpandaspython

Рекурсивная загрузка на yandex.ru

Рекурсивная загрузка встроенных ресурсов для актуальной версии Apache.JMeter 3.0 с настройками по умолчанию (html-парсер Lagarto) на сайте yandex.ruФрагмент html-кода сайта yandex.ru обработка которого добавляет новый шаг рекурсии, ссылки и картинка для скачивания Яндекс БраузераApache.JMeterApache.JMeterHtmlParser

  • есть ограничение на длину ссылок, и за счёт отсекания уникального окончания ссылки рекурсии не происходит;
  • или в Apache.JMeter 2.13, что-то неправильно работает в парсерах;
  • или в Apache.JMeter 2.13, что-то работает наоборот правильно — куки, ещё что-то и сам сервер Яндекса отвечает ему так, чтобы тот не уходил в рекурсию, например, отвечает картинкой на запрос картинки, а не новой html-страницей.

User-AgentUser-Agent

Состав проекта

  • jmeter.testfile.jmx — тестовый скрипт для Apache.JMeter 2.13 и Apache.JMeter 3.0 принимающий на вход параметры:
    • — адрес тестируемого сайта, например, https://yandex.ru/;
    • — строка по которой будет осуществляться группировка записей в логах, например, yandex.ru;
    • — количество итераций теста, используется несколько итераций из-за того, что работа веб-сайтов может быть нестабильной;
    • — парсер для извлечения ссылок на встроенные ресурсы;
    • для работы скрипта необходимо скачать и установить дополнительный плагин CsvLogWriter.
  • jmeter.3.0.bat — командный файл запуска теста для Apache.JMeter 3.0, тут задаётся путь к папке Apache.JMeter 3.0, путь к тестовому скрипту jmeter.testfile.jmx, опции запуска теста, а также список htmlParser-ов проверка работы которых выполняется;
  • jmeter.2.13.bat — командный файл запуска теста для Apache.JMeter 2.13, тут задаётся путь к папке Apache.JMeter 2.13, путь к тестовому скрипту jmeter.testfile.jmx, опции запуска теста, а также список htmlParser-ов проверка работы которых выполняется;
  • test.bat — командный файл запуска теста на двух версиях Apache.JMeter, 2.13 и 3.0, файл содержит количество итераций тестирования и адреса тестируемых сайтов. Файл вызывает файлы jmeter.2.13.bat и jmeter.3.0.bat;
  • jmeter.3.0.vs.jmeter.2.13.ipynb — блокнот для jupyter для анализа логов работы Apache.JMeter;
  • statistics.xlsx — таблица со статистикой по работе парсеров, результат исследования.

test.bat

Выводы

  • парсер в среднем извлекает ссылки только на треть ресурсов;
  • парсеры работают почти одинаково, а значит можно применять любой;
  • парсеры заточены под работу с простыми сайтами, такими как jmeter.apache.org;
  • на сайтах с большим количеством содержимого парсеры работают значительно хуже реального браузера;
  • полнота загрузки встроенных ресурсов в новой версии JMeter незначительно снизилась, а не возросла (на выбранных сайтах);
  • продемонстрировано прикладное использование плагина CsvLogWriter, логирующего запросы к embedded-ресурсам в csv-лог, который сделала моя коллега Александра Sanchez92;
  • с помощью bat-файлов, передачи парамеров JMeter через командную строку, логирования переменных и обработки csv-логов с помощью pandas можно тестировать сам инструмент тестирования, методика отработана, см. проект на github:

New and Noteworthy

UX improvements

Darklaf

Tree indentation level is easier to follow:


JMeter tree with Darklaf Darcula theme
JMeter tree with Darklaf IntelliJ theme

New look and feel themes. Light: IntellJ, Solarized Light, HighContrast Light.
Dark: OneDark, Solarized Dark, HighContrast Dark.

When an element in tree is disabled, all its descendants are shown in gray.
For instance, While Contoller is disabled in the following tree, so its children
are gray. It is purely a UI change, and the behavior is not altered.


While controller is disabled, so its children are gray

Tree context menu is shown even in case the node selection is changed. Previously
the popup did disappear and it was required to select a node first and only then launch popup.

Look and feel can now be updated without a restart

Use CTRL + ALT + wheel for zooming
fonts. Previous shortcut was CTRL + SHIFT + wheel,
however, it conflicted with horizontal scrolling.

In-app zoom is more consistent (e.g. sometimes not all the labels or even panels were scaled).
For instance: log viewer, JSR223 code editor were not previously scaled with zoom-in/out feature

Tree context menu is shown for the full row, not for the label only

Undo and redo support for editable fields. Keystrokes are CTRL + Z /
CTRL + SHIFT + Z, or
CMD + Z/
CMD + SHIFT + Z depending on the operating system.
Undo is implemented on a field level basis (each fields has its own history), and the history is
invalidated when tree selection changes.

Mark the currently selected language in the options menu.

Mark the currently selected log level in the options menu.

Rework of many Test Element UI (JUnit Request, ForEach Controller, If Controller, Throughput Controller, WhileController,
Counter Config, XPath2 Extractor, Function Helper Dialog, Search popup, JMS Elements)

3.10 Scoping Rules¶

The JMeter test tree contains elements that are both hierarchical and ordered. Some elements in the test trees are strictly hierarchical (Listeners, Config Elements, Post-Processors, Pre-Processors, Assertions, Timers), and some are primarily ordered (controllers, samplers). When you create your test plan, you will create an ordered list of sample request (via Samplers) that represent a set of steps to be executed. These requests are often organized within controllers that are also ordered. Given the following test tree:

Example test tree

The order of requests will be, One, Two, Three, Four.

Some controllers affect the order of their subelements, and you can read about these specific controllers in the component reference.

Other elements are hierarchical. An Assertion, for instance, is hierarchical in the test tree.
If its parent is a request, then it is applied to that request. If its
parent is a Controller, then it affects all requests that are descendants of
that Controller. In the following test tree:

Hierarchy example

Assertion #1 is applied only to Request One, while Assertion #2 is applied to Requests Two and Three.

Another example, this time using Timers:

complex example

In this example, the requests are named to reflect the order in which they will be executed. Timer #1 will apply to Requests Two, Three, and Four (notice how order is irrelevant for hierarchical elements). Assertion #1 will apply only to Request Three. Timer #2 will affect all the requests.

Hopefully these examples make it clear how configuration (hierarchical) elements are applied. If you imagine each Request being passed up the tree branches, to its parent, then to its parent’s parent, etc., and each time collecting all the configuration elements of that parent, then you will see how it works.

The Configuration elements Header Manager, Cookie Manager and Authorization manager are
treated differently from the Configuration Default elements.
The settings from the Configuration Default elements are merged into a set of values that the Sampler has access to.
However, the settings from the Managers are not merged.
If more than one Manager is in the scope of a Sampler,
only one Manager is used, but there is currently no way to specify which is used.

22.1 Passing variables between threads¶

JMeter variables have thread scope. This is deliberate, so that threads can act independently.
However sometimes there is a need to pass variables between different threads, in the same or different Thread Groups.

One way to do this is to use a property instead.
Properties are shared between all JMeter threads, so if one thread ,
another thread can the updated value.

If there is a lot of information that needs to be passed between threads, then consider using a file.
For example you could use the
listener or perhaps a BeanShell PostProcessor in one thread, and read the file using the HTTP Sampler «file:» protocol,
and extract the information using a PostProcessor or BeanShell element.

Generating Appropriate JMeter Logs

The default data logged during JMeter testing is quite sparse — important request and response fields are stored, but the full response sent back by the server is not stored. This is done to avoid bogging down the test client during load testing.

Using the following JMeter parameters on the command line generates log entries with corresponding higher detail for the test run.

The JMeter timestamp_format parameter can be used to specify logentry timestamps format. For eg:

As of April 2006, JMeter 2.1.1 must also be run with the following flag to ensure logfile uniformity:

The above settings can also be defined as global properties in the jmeter.properties configuration file, or in the user.properties file.

Оцените статью
Рейтинг автора
5
Материал подготовил
Андрей Измаилов
Наш эксперт
Написано статей
116
Добавить комментарий