I've been researching performance testing the large web application I develop at my job - mainly reading The Art of Application Performance Testing and using the web. It seems the best practice for generating test scripts (i.e., the things that simulate the user) is to use a "session recorder" while someone is using the application to capture all of the HTTP requests made, and then double check that those HTTP requests can be performed again (i.e., "replayed").

The problem I have is that the application I work on is write heavy - it's basically like Google Docs. Most interactions with the application involve users creating new entities, and then working on those entities.

A typical use case is that a user logs in to the system, creates a new Google doc, and then starts adding content. The problem is that every HTTP request sent after the user creates the document must contain a reference to the ID of the document. After performing session recording it seems I'd need to go over the record and manually substitute out the specific document ID with a variable name, so that I could replay the script with multiple users simultaneously. In my application's case we could be talking about hundreds of HTTP requests that would been to be edited.

This seems like it would take a very long time. It would also make it hard to deal with changing HTTP APIs - either the script would have to be manually changed, or the whole tedious recording process would have to be repeated.

Are there best practices around dealing with this kind of situation?

2 Answers 2


If you don't need a browser UI, JMeter can do this pretty easily.

You could record HTTP traffic in a browser using JMeter's proxy listener, although it sounds like the workflow might just involve a couple different URLs -- Maybe it's just a GET to /somehost/create and then a bunch of subsequent POSTs to /somehost/edit with the document ID.

If that's the case, you could set up a JMeter script that would call the first GET, store the document ID you're sent back, then do a bunch of timed POSTs with that ID and whatever content would simulate user activity.

And once the script is set up, you can tell JMeter to run as many of them at a time as you want. The timers and/or POST payloads could be randomized to replicate real-life usage as well.

  • The problem is that all of the subsequent requests (POSTs in your answer, though lots of other GETs) too require the document ID. I would need to manually edit each request to put the document ID in the right place...and we're talking about over a thousand subsequent requests. And this is just the document ID; users can also create other entities. Commented Feb 22, 2019 at 21:58
  • When you say "put the document ID in the right place", are you talking about putting it in a header? JMeter has a Header Manager that could store this once and inject it in every subsequent request. Or if it's a cookie, likewise there's the Cookie Manager for that. Or a parameter in the URL, same thing. Those could all be managed at the global level.
    – Andrew L
    Commented Feb 22, 2019 at 22:32
  • I'm aware that jMeter and Locust and all these tools offer ways to have variables that can be changed. My problem is more that I'm dealing with 1000 HTTP requests and going through each of them manually and substituting out the document_id for the variable name would be very tedious and flaky. Commented Feb 25, 2019 at 17:47

Yes, writes complicate automated performance tests. I dealt with a similar project by using a recording tool to capture some "canonical" user interactions, and then writing code to automate those interactions. The code took care of extracting IDs from responses and then injecting those IDs into subsequent requests.

  • I guess you can use pattern matching on the subsequent requests to inject the ID? Commented Feb 22, 2019 at 21:59
  • In your code, each request containing an ID becomes a template that contains a placeholder for an ID.
    – user246
    Commented Feb 22, 2019 at 22:28
  • Yeah this could work. I could also do some voodoo with the DB so that the next document_id generated is really large and would not collide with IDs of the other entities in the HTTP requests. Then I could do an automated search/replace. Commented Feb 25, 2019 at 17:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.