Open vlsi opened 1 year ago
Hi Vladimir,
Perhaps enhance the HTTP Mirror Server in JMeter? Bring the behavior of mock server inside
Frankly speaking, I thought behind the lines of "test-only" mock which is not included to the distribution.
If we migrate mirror server to undertow, it will bring more dependencies to the distribution, it would increase CVE burden.
It would be great if we could download plugins and dependencies on demand, however it would require configuring repositories, authentication, dependency verification.
Currently, Mirror Server is a part of :protocol:http
module (which is, well, understood and strange at the same time).
Here's the impact of adding undertow
dependency to JMeter distribution:
77872316 => 81394058 bytes (+3521742 bytes)
140 => 147 files (+7)
+ 60782 jboss-logging-3.4.3.Final.jar
+ 122607 jboss-threads-3.5.0.Final.jar
+ 2309706 undertow-core-2.3.6.Final.jar
+ 47396 wildfly-client-config-1.0.1.Final.jar
+ 284642 wildfly-common-1.5.4.Final.jar
+ 585204 xnio-api-3.8.8.Final.jar
+ 111405 xnio-nio-3.8.8.Final.jar
Use case
Fine-tuning HTTP samplers requires runing a server that could respond fast with minimal resource utilization.
What do you think if we integrate a small mock server into JMeter sources? I guess it would simplify to test performance-related changes.
Possible solution
I tried the following, and I got ~88K/sec for HTTPClient4 implementation and ~60K/sec for Java implementation (~8 threads, Java 17, M1 Max)
I guess we could predefined several routes (e.g. chunked encoding, large response, small response, etc).
The drawback would be to version churn (Renovate bot would ask us upgrading the versions as they release)
WDYT?
Possible workarounds
No response
JMeter Version
5.5
Java Version
No response
OS Version
No response