Hello everyone What is the recommended setting with regards

Question

Hello everyone What is the recommended setting with regards to the following configs to handle requests from users in the use case of a mock server ContainerThread JettyAcceptQueueSize AsynchronousResponseThreads

Oleg Nenashev · Answer

Hello I would recommend using defaults unless there is a specific need to tinker with them to solve a particular performance issue

Jackie chen · Answer

< Oleg Nenashev> the average response time of 100 concurrent users is 10 secs for a 5kb json response size With the following config containerThreads 50 JettyAcceptQueueSize 100 AsynchronousResponseThreads 150 AsynchronousResponseEnabled true It takes so long

Oleg Nenashev · Answer

10 seconds he s definitely quite high though it depends on the system resources available to the instance What is your current jvm and system configuration if container VM actual limits

Jackie chen · Answer

Im running wiremock as a server on a 32GB memory and 8 core CPU mac locally then run jmeter with 100 concurrent users on the same machine

Oleg Nenashev · Answer

What are your current jvm settings Maybe it makes sense to just run a tool like jvmtop it provides good insights ootb

Jackie chen · Answer

< Oleg Nenashev> i use the default jvm setting with xms2g xmx4g and the default setting give the same result of 10 secs for 80 100 concurrent users With jvmtop HPCUR is ~800m to 2400m HPMAX is 3600m

Jackie chen · Answer

PID MAIN CLASS HPCUR HPMAX NHCUR NHMAX CPU GC VM USERNAME T DL 35247 wiremock jar 819m 3793m 135m n a 69 86 0 20 O8X39 jackie c 152 35173 m jvmtop JvmTop 91m 7282m 23m n a 0 11 0 00 98U36 jackie c 20 35256 pacheJMeter jar 172m 1024m 44m 744m 0 08 0 00 68U31 jackie c 93

Oleg Nenashev · Answer

These settings are definitely quite low for this server size even with jmeter there and for 50 containers threads For a common Jetty receiver I would generally recommend at least 64Mb per thread up to this 256 depending on the payload and one virtual core if you want to do load testing

Oleg Nenashev · Answer

Maybe you also want to put more response threads because right now it doesn t seem to be saturated too But I can t say for sure without profiling

Jackie chen · Answer

sorry my typo i configured ContainerThreads 150 do you mean it should be 64MB 256MB for this param how about jettyAcceptQueueSize

Oleg Nenashev · Answer

Without profiling hard to give any recipe TBH

Jackie chen · Answer

with 40 concurrent users xmx10g containerThreads 200 jettyAcceptQueueSize 100 asynchronousResponseThreads 200 the avg response time is 6 7 secs attached the profiler info

Oleg Nenashev · Answer

It seems the CPU is saturated but not 100 sure Do you get queue rejections And how many CPU cores are assigned to the process

Jackie chen · Answer

i am running it on a physical mac machine which has 8 CPU cores and 32 GB of RAM i found out that the issue is caused by the number of stub mappings with 167 stub mappings it takes 21 secs for 100 concurrent users while it takes 300 ms for 100 concurrent users when there are 4 stub mappings my test scenario is just getting one stub mapping

Oleg Nenashev · Answer

Hmm Would be an interesting performance test scenario I suppose something is wrong with Stub matching and expression overheads there I wish I had access to those 167 stubs but I do have a few ideas based on the quick code check < Tom> By chance are there any JMH tests for this part

Tom · Answer

We don t have any JMH benchmarks at the moment but when we see high response times like this it s usually one of two reasons 1 The request log isn t disabled or constrained so the VM ends up spending a lot of time in GC 2 There are a lot of stubs present with complex match criteria `equalToXml` and `equalToJson` tend to be the most demanding when the request bodies have large numbers of nodes Record and playback of e g SOAP APIs tends to produce this outcome as it s very easy to generate lots of stubs with big expected XML request bodies

Jackie chen · Answer

Response time is still very high when request journal is disabled in this case there are 167 stub mappings with equalToXml 163 stubs stubbed by Record amp Playback feature with few xmlunit placeholder $ xmlunit ignore my test scenario that reproduces the issue gets only one equalToJson stub mapping the request body is not large but response xml is large do you have a plan to optimize this use case

Oleg Nenashev · Answer

i guess we have enough information for a JMH based repro test by now I guess the fetching time could be improved maybe via some caching or stub routing improvement e g checking the previous match as a the first option when processing patterns

Tom · Answer

How large are your responses Usually these can be pretty big without it being an issue but above a certain size + with gzip enabled can sometimes be significant

Tom · Answer

I still suspect that request matching is the issue though One thing to try would be to convert as many stubs as you can to use `matchesXPath` instead assuming you can pick one or two elements in the XML body that uniquely identify the request

Jackie chen · Answer

```How large are your responses ``` response size is ~320 KB request size is ~1 1 KB with response content encoding gzip

Oleg Nenashev · Answer

I think it should not matter since the actually invoked response is a JSON one Especially for so bulky server So the bottleneck should be on the matcher side

Tom · Answer

Wouldn t hurt to try turning gzip off and seeing what the effect is

Jackie chen · Answer

```I think it should not matter since the actually invoked response is a JSON one ``` you re right i only call the same equalToJson one scenario only but i see hotspots in EqualToXml TransformerFactoryImpl classes as per attached