I installed SonarQube to help with code quality analysis. I set it up to run behind an Nginx reverse proxy using the instructions on their website. Often I have to wait exactly one minute to load a page. Upon investigation using Google Chrome Developer Tools, I saw that a resource was not loading for exactly one minute. Then, something times out and allows the page to continue to load. Here's a typical example of the problem, where some resources load at the beginning, then there's a one minute delay, then the rest of the page loads:
Sometimes the page loads without any delay.
At first I thought it might be a problem with some JavaScript. Here is an example of clicking around to many pages, and sorting by response time (to see resources might be causing the delay):
I then tried loading a static image, and even that intermittently takes a minute to load.
How can I pin down exactly what component is causing the delay? Could it be the reverse proxy? The SonarQube application? Some JVM problem?
As your 1mn delay happen also with static image (here logo), where there is minimal JVM impact, I would suggest to use curl -L -v against Nginx front end and also directly to SQ HTTP connector.
If 1mn delay never happen when connection to SQ HTTP connector, Nginx / SQ link should be investigated.
If 1mn delay happen also with SQ HTTP connector, SQ JVMs and hosting should be investigated
Related
I use JMeter for checking load testing.
I note a time with stopwatch when i check load time personally it was
8.5 seconds
when i run same case with JMeter it gave load time of 2 seconds
There is huge difference between them, How can i verify the actual time?
e.g : if one user taking 9 seconds to load the form while in JMeter it is given load time 2 seconds
Client time is a complex item, as you can see from the clip from the Chrome Developer tools, performance tab, above. There's lots going on at the client which does lead to a difference between the time you see with an HTTP protocol test tool, such as JMETER (and most of the other performance test tools on the planet) and the actual client render.
You can address this Delta in a number of ways:
Run a single GUI Virtual user. Name your timing records such as "Login" and "login_GUI." The delta between the two is your client weight. Make sure to run the GUI virtual user on a dedicated host to avoid resource contention
Run a test with all browsers. This was state of the art in 1995. Because of the resource cost and the skew imposed on trying to figure out the cost of the server response the entire industry shifted to protocol level virtual users. Some are trying to bring back this model as "state of the art." It is not
Ask a performance question earlier, also known as "shift left..." Every developer has these developer tools at their disposal, as does every functional tester. If you find that a client is slow for one user, be curious and use the developer tools to identify, "why?" If you are waiting to multi user performance testing to answer questions related to client weight, then you have waited too long and often will not have the time or resources to change the page architecture in meaningful ways to reduce the client page cost. This is where understanding earlier has tremendous advantages for making changes.
I picked the graphic above deliberately to illustrate the precise challenge you have. Notice, the loading of the components takes less than a tenth of a second. These are the requests that JMETER would be making. But the page takes almost five seconds to "render." Jmeter is not broken, it is working as designed. It is your understanding that needs to change on which tools can be used to pull particular stats for analysis.
You can't compare JMeter load time to browser as is, also because your browser will load JavaScript files and can call JavaScript functions on page load while JMeter doesn't execute JavaScript.
JMeter is not a browser, it works at protocol level. As far as
web-services and remote services are concerned, JMeter looks like a
browser (or rather, multiple browsers); however JMeter does not
perform all the actions supported by browsers. In particular, JMeter
does not execute the Javascript found in HTML pages. Nor does it
render the HTML pages as a browser does (it's possible to view the
response as HTML etc., but the timings are not included in any
samples, and only one sample in one thread is ever displayed at a
time).
Just a side note - you can use plugin to check exact load time in chrome.
Well-behaved JMeter test timing should be equal or similar to real user timing, if there is a 4x times difference - most probably your JMeter configuration is not correct.
Probably the most important. Make sure your HTTP Request samplers are configured to retrieve so called "embedded resources" (images, scripts, styles) which are referenced in the web page
If your application is using AJAX technology make sure you execute AJAX-driven requests as well and add their elapsed time to main sampler using i.e. Transaction Controller.
Make sure you mimic browser's:
Cookies via HTTP Cookie Manager
Headers via HTTP Header Manager
Cache via HTTP Cache Manager
Assuming all above you should be receiving similar to real user experience page load time. See How to make JMeter behave more like a real browser article for more detailed information on the above tips.
In addition to the answers provided by James and user7294900, please find these images to help you understand the reason behind the difference in time given by your stop watch and JMeter.
Below image gives the ideology behind how JMeter provides the time.
Below image gives the ideology behind how you have measured the time with
your stop watch.
Notice that there are additional actions performed by the browser when you are taking the time using your stop watch. This is the reason behind the huge difference in time between JMeter and your stop watch.
In addition to this, ensure that you are using the same test environmental conditions for both the tests (like same network conditions, same LG etc.)
Hope this helps!
Across all browsers/devices, I find random different pages, at random times, are very slow to load/don't load. The browser is stuck on 'Waiting for website.com'. I will wait 20 seconds and nothing will happen until I manually refresh the page. As I realise this is very vague, can you suggest a) most likely issues to look for first or b) some diagnostic tools that I could use to try and de-bug the issue as a starting point, so that my hosts/developers can solve the issue. Here are some results of recent speed tests.
One thing to also add is that, it seems it more often gets stuck on particular pages. Namely the pages where users take practice tests. After each time the user clicks 'Next', their selected answer is inserted into the database. My speculation is that potentially it's an issue with the DB itself, or the process which inserts into the database. It's when clicking 'Next', that the whole website sometimes just dies as described above.
Results from Google Speed Test
Waterfall image
A wait time of 20secs at random times and random pages could possibly be due to stop-the-world garbage collection. So GC logs are probably a good starting point.
A thread sampler such as Djigger a colleague of mine wrote might probably also help you figuring out what the machine is doing during the 20 seconds.
If that doesn't help I suggest to use a Profiler or better an APM tool to monitor whats going on on your system. Those tools give a you a broader insight of the internals.
You need to run a few page speed tests and look at the waterfall images.
It is very common on shared servers for the server to be too busy to get to your request. 20 seconds would indicate a serious issue with the server.
Another common reason is the page has a link to a third party resource and that resource is too often unavailable.
In your case the culprit is website.com and I assume that is your site.
Use something like webpagetest.org to run the tests.
In the waterfall image below
Dark Green is DNS lookup time.
Orange is the time for Browser to connect to server.
Green is the wait time for server to put image in output buffer.
Blue is the time for the server to transmit to the Browser.
The problem with the sample waterfall page is the index page took 4 seconds to be generated or retrieved. Most likely this is a Word Press site with plugins.
I suspect yours may be 20 seconds. But due to the randomness, is is also a good possibility it is a page resource that is stalled.
If it is the index page, then you likely have a poor ISP and or one of the other users of the server is hogging the CPU.
Keep running the tests until you see the problem occur.
It will be very obvious where the problem is located.
You can post the waterfall image and send me a message if you have any questions.
Waterfall from webpagetest.org
I have set up a test plan using Apache JMeter, but when testing a remote server I am seeing much slower times than it takes the browser to run the same test, it's on order of 5-10x slower. For example chrome takes about 300ms to load a simple static page with some embedded assets while jmeter reports 2000+ms for the same page from the same machine.
I've tried tweaking the thread count to make sure this is not the bottleneck as well as not too much load slowing down the server, but nothing seems to change these slow numbers.
What else can I look at to get more realistic response times out of this tool?
I figured this one out, the issue was that "Retrieve all embedded resources" was checked, which I want, but I was also not using the "concurrent pool size" option, so it was cycling through each of the ~10 embedded HTTP requests on the page serially and reporting slow overall load times. Checking this and adding a realistic browser concurrency number (Chrome uses 6 these days so that's what I went with: http://sgdev-blog.blogspot.com/2014/01/maximum-concurrent-connection-to-same.html)
give me numbers that are very close to real browser testing.
Make sure you add HTTP Cache Manager as browsers download embedded stuff like images, scripts, styles, etc. but do it only once, on subsequent requests aforementioned resources are being returned from browser's cache, no actual request is being made.
See How to make JMeter behave more like a real browser guide for other recommendations on how to make your JMeter test more realistic.
I'm trying to simulate a connection to a website. The goal of the simulation is to collect statistics on page loading time on browser side.
I configured JMeter Flagging the option Retrieve Embedded Resources in order to simulate the real time to load the whole page. The issue is that while from a real Browser i have a response time (let's assume for the page A the response time is 10 seconds) in JMeter I found i response time 20 times higher.
It seems JMeter takes a much longer time to gather embedded resources (e.g. js, images, ...)
Do you have any suggestion for this issue?
Kind Regards
Update 31/07
I discovered some resources are not completely downloaded. Using Firebug i see some components with 0 bytes downloaded that the browsere keep trying to download (but the user do not percieve since the page is loaded). Therefore i suspect JMeter keeps trying downloading it. Is there any chance to set a timeout to overcome this kind of situation?
Update_1 31/07
I figured out that the issue is related with nested iframes. setting httpsampler.max_frame_depth=0 i get the correct time. however i would like to understand the reason of this issue. Do I have to set other paramters?
Disable browser cache and re-run your test in browser.
Jmeter will not store cache, unless otherwise specified.
Hope this will help.
Add a HTTP Cache Manager to your test plan.
Real browsers retrieve images, scripts, styles, etc. but do it only once. In order to simulate browser behavior you need to configure JMeter appropriately.
See How to make JMeter behave more like a real browser guide for more test elements which can be used for this.
for testing purposes I measure the time it takes for parsing, db accessing, posting and rendering of one of my web php web pages in the browser (by using Firebug's network tool). When I press F5 after clearing the cache by "Delete recent data" it takes about 5 seconds, when I hit Ctrl-F5 it takes about 20 seconds.
Isn't that the same? What's the difference between them? What is the recommended way to test the performance of php code and db access?
Thank you very much in advance ...
There could be any number of reasons all of which have to do with the implementation of firebug.
You cannot test the performance on the client side since clients differ a lot and also have the network latency which is even harder rule out.
You should do this all on the server side: start a timer when the request reaches your web server and then stop it when it exits. If that is a bit difficult then in the PHP script itself you can run a wrapper script that has a start timer, a require statement for the script you want and a stop timer.