3

Is there any way to make WireMock Standalone faster? I have 1kb response file that I want to get back between 3ms - 10ms Currently the response is coming back within 20ms - 40ms

This is for an individual request/response from SoapUI, so it also needs to scale under load, although I believe this can be accommodated using the command line switches/Jetty parameters

Machine is 2x2.8 GHz (64 bit) / 32GB Ram

Joakim Erdfelt
  • 46,896
  • 7
  • 86
  • 136
DawnFreeze
  • 164
  • 1
  • 3
  • 13
  • Are you using files or is the body specified in the mapping definition? – Tom Jun 28 '17 at 08:03
  • WireMock has nothing to do with performance and never will. Doing performance testing this way gives you no useful information about Jetty or your SoapUI, it only tells you about the performance of WireMock. – Joakim Erdfelt Jun 28 '17 at 12:14
  • @Tom Yes, everything is pretty flat other than using a transformer for correlation (but I am getting the same result when I remove it. It is an xml file in __Files, and uses a simple xpath match – DawnFreeze Jun 28 '17 at 20:21
  • @JoakimErdfelt Not sure what you are getting at here. I need to turn my app into the bottleneck when under load, and in order to do so I need WireMock to respond in < 10ms max. I am only using SoapUI to time requests. – DawnFreeze Jun 28 '17 at 20:23

1 Answers1

4

You might find that putting the response bodies directly into the stub mappings works better (which you can do as base64 if they're binary).

Currently WireMock reads body files from the filesystem each time they're served, so you're probably taking a hit on I/O latency. When they're part of the mapping they're held in memory.

Another alternative if you have the option would be to mount the __files directory on faster storage e.g. a ramdisk.

Tom
  • 3,471
  • 21
  • 14
  • Thanks Tom, this has definitely improved the performance (just used raw XML with escape characters in the mapping file), it is now consistently between 13-20ms. Do you think that is as fast as it will get? – DawnFreeze Jun 29 '17 at 22:39
  • This isn't something I've ever benchmarked or tuned specifically, so I couldn't say how fast it's reasonable to expect. – Tom Jun 30 '17 at 16:00
  • Where are you measuring from? Is that 13-20ms round trip from the point-of-view of your client? And are you calling it over an actual network or your machine's loopback adapter? – Tom Jun 30 '17 at 16:01
  • Measuring from the client over network, round trip, so travel time is included. Its consistent over thousands of requests, so its an accurate indication of processing speed. It will probably be faster locally, however the remote machine infrastructure is necessary. – DawnFreeze Jul 02 '17 at 20:49
  • It'd be interesting to see what the timings look like locally so that you can control out the effects of the network. Also, are you pooling connections or reestablishing each time? – Tom Jul 03 '17 at 12:03
  • Ok, I tested locally, consistently 13-15ms with no connection pooling, re-establishing connection each time. – DawnFreeze Jul 03 '17 at 20:42
  • That doesn't sound too bad to me. Establishing TCP connections isn't particularly cheap. Maybe worth enabling pooling and see how that performs? That way you've eliminated the effects of both the wire time and the TCP initiation time. – Tom Jul 04 '17 at 14:12
  • Just some context to make more sense of my initial query, I am currently using another tool which I am looking to replace (WireMock is a far more elegant solution for my requirements) which consistently performs < 5ms when running on the same machine and under the same circumstances. – DawnFreeze Jul 05 '17 at 02:06
  • @DawnFreeze which tool was performing at <5ms ? – Wojtek Jan 12 '18 at 16:22
  • @Wojtek CA Lisa DevTest VSE – DawnFreeze Jan 18 '18 at 22:13