| || |
In my project I have to get the response time for each page.
I am using timers for each page with synchronize requests. But I am confused with where to place synchronize requests command.
There are two options with me.
1) Before End Timer.
2) After End Timer before next start timer.
In most posts I have read that synchronize requests should be placed just before End Timer.
But confusion is that if I place synchronize requests before End Timer statement than the thread replay currently executing to be suspended immediately, until responses have been received for all the requests that have been issued by the thread. In this case all the completed requests (For example 10 VU are there) could show same response time.
Please help me out to resolve this confusion.
Re: SYNCHRONIZE REQUESTS
Think of it this way;
Your script will execute as asynchronously as possible. Statements that cause the script to pause are;
- get or post on a channel id that is currently waiting for a response
- load response_info statement
- Disconnect statement
- wait statement (including wait for semaphore)
- synchronize requests statement
- acquire mutex
Most of these statements when executed by one VU's script will NOT effect behavior of another VU running the same script (exceptions are semephore and mutex commands), i.e. a synchronize requests statement executed by VU 1, will not effect any other VU's script execution.
My rule of thumbs are;
- Comment out all wait statements (global search/replace)
- insert wait statement in key places to control pacing. Generally after “end timer” statements but not between start time/end time statements.
- Know the target script work rate and check to see if the sum of the wait times makes sense
- Insert “SYNCHRONIZE REQUESTS” statement after all primary get/post requests.
- Insert “SYNCHRONIZE REQUESTS” statement prior to “start timer” and “end timer” command (to be sure you are not including some work already in progress.
These are rules of thumb and as such do not work in all cases. You need to get a good mental picture of how the application behaves and also the work habits of the users.