Коллеги, добрый день!
Тестирую SOAP-сервисы через JMeter. Подскажите, пожалуйста, как должны заполняться SOAPAction в HTTP Header Manager и Path?
Про SOAPAction нашёл следующее: "Some webservices may not use SOAPAction in this case remove it. Currently, only .NET uses SOAPAction, so it is normal to have a blank SOAPAction for all other webservices. The list includes JWSDP, Weblogic, Axis, The Mind Electric Glue, and gSoap." Если же поле должно быть заполнено, то что именно должно быть в нём указано? Путь к WSDL сервиса?
Параметр Path в примере заполнен значением "/WeatherWS/Weather.asmx". Правильно ли понимаю, что для моих запросов нужно будет указать пути к WSDL тестируемых сервисов?

Читаю книгу art of perfomance testing.
И возникла куча вопросов по снятию метрик.
Например :
Data volume:

The amount of data presented to the network. As discussed, this is particularly important when the application will have end users connecting over  bandwidth WAN links. High data volume, when combined with bandwidth restrictions and network latency effects, does not usually yield good performance.

Data throughput

The rate that data is presented to the network. You may have a certain number of page hits per second as a performance target. Monitoring data throughput will let you know if this rate is being achieved or if throughput is being throttled back.
Often a sudden reduction in throughput is the fi rst symptom of capacity problems, where the servers cannot keep up with the number of requests being made and virtual users start to suffer from server time-outs

Data error
rate Large numbers of network errors that require retransmission of data may slow down throughput and degrade application performance. Ideally, there should be zero network errors present; however, the reality is that there will almost always be some. It is important to determine the nature and severity of any errors that are detected and whether they are related to the application or to problems with the network infrastructure. Packet sniff i ng technology, as provided by the popular Wireshark toolset, can be extremely insightful when you are investigating net-work problems.

Какимими тулзами снимаются данные метрики.?

Все зависит от кейса, можно использовать Wireshark
Как сказано в последнем пункте "Wireshark toolset, can be extremely insightful when you are investigating net-work problems."

Но вообще это хорошо ложится на мониторинг. В перформанс тестинг энве все должно быть покрыто мониторингом.
И можно вывести на дашборд уровень трафика, а так же ошибки и ретрансмиты

Все зависит от кейса, можно использовать Wireshark
Как сказано в последнем пункте "Wireshark toolset, can be extremely insightful when you are investigating net-work problems."

Но вообще это хорошо ложится на мониторинг. В перформанс тестинг энве все должно быть покрыто мониторингом.
И можно вывести на дашборд уровень трафика, а так же ошибки и ретрансмиты

Вот есть пример
https://jmeter.apache.org/usermanual/build-ws-test-plan.html

https://jmeter.apache.org/images/screenshots/ws_header.png

Action - имя метода в пространстве имён указанном в XML SOAP WSDL, этого адреса, узла может вообще не быть.

А WSDL - обычно доступная для запроса ссылка

Хотя, перечитал спеку телеграфа , он тоже это могет

Кстати, есть канал по мониторингу и метрикам, там в основном прометеус, но все же
https://t.me/metrics_ru

Зашел, почитал. Там исповедуют ClickHouse

Apache.JMeter, Gatling, Yandex.Tank, LoadRunner Enterprise поддерживают отправку метрик в InfluxDB. В тестировании производительности нет аналогов InfluxDB.

А этот инструмент размазан аргументами вида - плохо работает с огромными базами данных (250 ГБайт RAM, видимо, не меньший размер базы) и много ошибок, например при работе с Prometeus (приведена ссылка на telegraf, а это отдельный продукт), модуль экспорта новый совсем и сырой, что от него ждать, и вообще это конкурент.

https://github.com/freeseacher/metrics_ru_faq

Думаю это правда. И всё так.

Но моё мнение, что метрик не должно быть под терабайт. Это как надо накопить столько - логи сырым текстом слать?
И знание того, что хранилище не может переварить любые данные заставляет осознанно подходить к хранению, к выбору метрик. Это уже маленький, но залог того, что на метрики будут обращать внимание. Что они будут работать.