How can I optimise CPU consumption when my server returns a 0.5MB json body?

I have a test with 30k virtual users and I am running the test from a c5.4xlarge amazon instance. (16 CPU)
When I get to a stage where all my users are receiving a 0.5MB JSON body, the CPU on the machine maxes out and the test starts to fail.
I can imagine this is happening because parsing/validating so many huge responses like that takes it toll.
Is there any way to optimise gatling on that particular call? Maybe stop it from parsing the JSON?
If I am not using jsonpath, I will however need to find a particular String on the return body to validate the response.
Any assistant or direction on how to resolve this would be highly appreciated.

  • run on a larger machine
  • use FrontLine to distribute test on multiple machines
  • become a FrontLine customer so you get personal support and we can investigate your special use case, which we can’t do for Gatling OSS unless you provide a way to reproduce your issue

I ran into similar technical challenge when 25K+ virtual users each had to parse JSON payload of 1-20MB in size. The system ran out of memory, not CPU.

  • I first replaced JsonPath with regex, which probably applies to your usecase of finding a particular string for validation.
  • I eventually implemented JSON streaming parser using Jackson for robustness.

Thanks for your feedback, Vu, you have a very good point.

JsonPath, JMESPath and XPath all have back-tracking features, eg:

  • I want a child of a node that has another child that matches a given criteria
  • I want the n-th element of an array counting from the end
    Such features require buffering and would be extremely challenging to implement without an in-memory AST (named DOM for XML).

Such AST indeed uses a lot of memory. You can expect 3 times the size of the binary stream, sitting altogether in-memory.

Using streaming parsers, a la SAX, would indeed save a lot of memory.
Then comes the difficulty of implementation. You need to be a coder to parse a stream with such library/API.
I’m not aware of any path-based standard for XML or JSON that would have less features (no wildcard, filters only on current node, no counting from the end…) so it could be implemented on an event-emitting parser.
Suggestions welcome.