As you can see the second request starts 784ms after the beginning. I wonder why that request starts at 784ms instead of 741ms (directly after the first one)?
What happens in the 43ms in between the first and second request? There is no indicator showing that there is a blocking request.
The 43ms between the two requests indicate the parsing time. I.e. this is the time needed to process the request to the page URL you requested and find embedded resources like images, JavaScripts, etc., which need to be loaded.
So there will always be a gap between the first request and the second.
The same happens for requests to other resources like CSS files. Their contents first need to be interpreted after their download to know the other resources they include like e.g. images, web fonts or other CSS files.
Related
I had recorded the script using blaze meter plugin, and using ultimate thread group, I am not able to figure out:
Why there is delay in sending first request? I have not set any delayed and start-time is also for 1 second
Also in my result tree I am seeing multiple http requests called. What am I doing wrong here?
We are not telepathic enough to guess why do you have the "delay" without seeing your test plan, most probably there is something like "Think-Time" or other Timer there
having non-zero "Thread Delay" value. This is to simulate real user using the real browser. Real users don't hammer the application under test non-stop, they need some time to "think" between operations so most probably this delay is due to the timer action
If you look at Defaults configuration element at the "Advanced" tab there is a setting instructing JMeter to download so-called "Embedded Resources". In the main HTML response there are multiple referenced elements like images, scripts, styles, fonts, sounds, etc. and JMeter parses the main HTML response, extracts these resources from there and downloads them as this is what real browsers do.
While navigating to e.x landing page the blazemeter recorder gives 10 HTTP requests. In this case, how can i get, how much time taken to navigate landing page.
If I summarize all the requests time based on View Results in Table listener, it is more than the reponse time of chrome time hence couldn't get the exact time.
Note: HTTP Request might be sequential or parallel.
Chrome Response time is 4sec but View Results in Table listener sum value is 12sec
I don't think you should have 10 requests, most probably you should have only 1 request.
If remaining 9 requests are for images, scripts, styles, fonts, sounds, etc. - you don't need to add them manually, instead you need to tick Retrieve all embedded resources and Parallel Downloads boxes on "Advanced" tab of the HTTP Request sampler (or even better, HTTP Request Defaults:
If the requests are AJAX - you need to put them under Parallel Controller
I want to test a fully functioning website for load using a constant, known number of users - to that end I'm trying to recreate the "Retrieved All Embedded Resources" functionality for a web-page, only manually, because I really don't know if it fetches all resources grabbed by JS. So the first question is - how do I check to see what these subsequent fetches retrieve?
Second question is - how do I make the multiple requests atomic, like "Retrieve All Embedded Resources"? I need to use "Constant Throughput Timer" for making sure the number of vusers is constant, but:
When using "Retrieve All Embedded Resources", this counts as one request, and one thread handles it right (hopefully, again - can't tell what goes on beyond the scenes)
When using a recorded session with numerous elements, each element is one action and occupies the queue (counts as 1 sample for Constant Throughput Timer). Therefore, it's not atomic.
I guess I can count the elements and define them as number of samples for throughput per minute, but this won't do in the long run.
First of all, jmeter does not execute any javascript in the pages retrieved. Clicking "Retrieve all embedded resources" does the following if you check the documentation:
Tell JMeter to parse the HTML file and send HTTP/HTTPS requests for all images, Java applets, JavaScript files, CSSs, etc. referenced in the file.
So it will check the current sample for any references and retrieve those, but it will not run any scripts that are retrieved.
If you want to check which resources jmeter is actually retrieving you could run for example Fiddler to check which requests are being made.
You can use Transaction Controller to consider all embedded resources requests and master request as one sample, aggregate time will be logged and reported.
I have this strange issue where sometimes if I make two AJAX requests to my Apache 2.2 server in rapid succession, the second request will wait for the first to finish before finishing.
Example, I have two requests, one that sleeps for 10 seconds and one that returns immediately. If I run the request that returns immediatly by itself it will always return within 300ms. However, if I call the request that takes 10 seconds, and then call the request that returns right away about 50% of the time the second request will wait until the first finishes and chrome will report that the request too about 10 seconds before receiving a response. The other half of the time the quick request will return right away.
I can't find any pattern to make it behave one way or another, it will just randomly block the quick AJAX requests sometimes, and other times it will behave as expected. I'm working on a dev server that only I am accessing and I've set several variables such as MaxRequestsPerChild to a high value.
Does anyone have any idea why Apache, seemingly at random, is turning my AJAX requests into synchronous requests?
Here is the code I'm running:
$.ajax({async:true,dataType:'json',url:'/progressTest',success:function(d){console.log('FINAL',d)}}); // Sleeps for 10 seconds
$.ajax({async:true,dataType:'json',url:'/progressTestStatus',success:function(d){console.log('STATUS',d)}}); // Takes ~300ms
And here are two screen shots. The first where it behaved as expected and the second where it waited for the slow process to finish first (in the example the timeout was set to 3 seconds).
UPDATE: Per the comments below - this appears to be related to Chrome only performing one request at a time. Any ideas why Chrome would set such a low limit on async requests?
The problem is not with Apache but with Google Chrome limiting the number of concurrent requests to your development server. I can only make guesses as to why it's limited to one request. Here are a couple:
1) Do you have many tabs open? There is a limit to the total number of concurrent connections and if you have many tabs making requests with KeepAlive you may be at that limit and can only establish one connect to your server. If that's the case you might be able to fix that by adding KeepAlive to your own output headers.
2) Do you have some extensions enabled. Some extensions do weird things to the browser. Try disabling all your extensions and making the same requests. If it works then enable them one at a time to find the culprit extension.
I have the exact same html sitting on two different servers. Both pages call things like stylesheets and images from the same servers (not each from their local server). In other words, these pages are identical except they exist on two different servers. It's all static html. The only DNS lookups are for images.
On one server it takes 25 seconds to load, and it appears most of that is waiting on the html page itself
http://tools.pingdom.com/fpt/#!/CmGSycTZd/http://205.158.110.184/contents/mylayout/2
On another server it takes under 2 seconds to load
http://tools.pingdom.com/fpt/#!/rqg73fi7V/http://socialmediaphyte.com/TEST/image-dns-testing-ImageON.html
The only difference I can ID from Pingdom is "Connection." The slow server responds with "close" and the fast server responds with "Keep-Alive". Is THAT the most likely issue? Or is it possibly something else? (And if you know the remedy for your suspected cause, that would be wonderful.)
Thanks!
Not using keep-alive will slow the overall load time a bit because you incur the additional overhead of having to establish a new connection for each resource, rather than re-using one or more connections. This shouldn't equate to 23 seconds difference though.
Using the FireBug Net Panel for Firefox can be of great assistance in seeing what is taking so long. It shows you how long each requested resource from the page took to load, and how long each phase of requesting the resource took.
Other factors could include one server is using gzip compression on pages and the other is not, or it could just be overloaded.