Need help with StresStimulus? Start here.
Concurrency mode
|
sachpatel Posts: 12
2/22/2021
|
Hi,
This question was with regards to replaying scripts and customising the "Concurrency mode" option. I understand there are a couple of options at the script level that can be used (Concurrency mode: Content-type, recorded concurrency). I have tested both options using the following scenario: 3 users, 2 iterations. These are the tests I ran:
1) Concurrency mode = Content-type (at the script level)
2) Concurrency mode = Recorded Concurrency (at the script level)
3) Customised the concurrency mode to "parallel" for a couple of transactions (at a transaction level)
Looking at the 95th percentile, the response times varied differently compared to what is captured in Dev Tools when going through the transactions manually.
1) Much slower
2) Much faster
3) More accurate
What is the best/quickest way to determine the script is replayed in an accurate manner to obtain more realistic response times when running as part of a load test? It seems very time consuming to have to go through each transaction with Dev tools open to determine which transactions are executed in parallel, sequential, etc.
Thank you.
|
|
|
0
link
|
|
George @StresStimulus Administrator Posts: 554
2/22/2021
|
Dev tools capture the request/response time (server + network time) and page rendering with javascript processing time (client time).
Load testing only measures times that depend on the load/concurrency of shared resources (server + network time).
However, you can configure StresStimulus to emulate client time by adding recorded delays into the script as described here.
I would recommend using recorded concurrency mode with adding the emulated client delays for the most accurate results.
- Cheers
|
|
|
+1
link
|
|
George @StresStimulus Administrator Posts: 554
2/23/2021
|
Let me unpack it:
Regarding your visual observation: StresStimulus measures: StresStimulus page response time and visual impression of page responses can be apple and oranges. Here is one reason for that. StresStimulus measures time between the first and last request. On the other hand, when you visually determine that the page is loaded, you do not know whether any resources are still being loaded and whether the page DOM below the fold is still being generated.
Regarding DevTools and StresStimulus time: Response time is a product of a client sending requests and the server sending back responses. To investigate your findings, you need to compare the behaviors of DevTools and StresStimulus. Execute a test with one VU - one iteration to provide the same server load as with DevTools. Then compare the waterfall diagrams in StresStimulus and Dev tools. StresStimulus waterfall diagram is described here. Then execute StresStimulus tests with various concurrency settings and see the difference
Regarding StresStimulus Concurrency modes: You are correct that Recorded Concurrency determines requests are sequential or parallel based on the recorded waterfall. A request is parallel if its response comes after the next request is sent, otherwise, it is sequential.
The Set-cookie header enforces sequential requests property is described here. You can set it to No if you have many responses with Set-cookie header that is causing sequential requests and you wish to send them in parallel, however, make sure setting this property doesn’t break your script.
- Cheers
|
|
|
+1
link
|
Copyright © 2024 Stimulus Technology