This message was deleted.

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

@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.

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)?

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

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

@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

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

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

Without profiling, hard to give any recipe TBH

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

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?

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.

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?

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.

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 & 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?

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)

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.

How large are your responses?

response size is ~320 KB, request size is ~1.1 KB with response content-encoding: gzip

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

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

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.