I'm trying to test some custom page timing code which times PHP execution time, SQL query time and the time the browser actually takes to render the page to the client.
How can I slow XAMPP down so page loads take a few seconds, so I can more easily measure timing?
Related
When i executes a HTTP-request to Laravel's API (e.g. /api/devices) wia Postman, the execution time is ~1000ms.
When same HTTP-request executes from Front on React-Redux, the TTFB (time to first byte) gains to 3000-7000ms.
SQL query logging shows times up to 50ms per query (~10 queries), but Enter point's (public/index.php) execute time is only 1-3ms.
Where should i look for a problem??
Use Barryvdh's debug bar.
It will provide full profiling information for your app and let you know where the slow-down is.
We are currently conducting performance tests on both web apps that we have, one is running within a private network and the other is accessible for all. For both apps, a single page-load of the landing page or initial page only takes between 2-3 seconds on a user POV, but when we use blaze and JMeter, the results are between 15-20 seconds. Am I missing something? The 15-20 seconds result came from the Loadtime/Sample Time in JMeter and in Elapsed column if extracted to .csv. Please help as I'm stuck.
We have tried conducting tests on multiple PCs within the office premises along with a PC remotely accessed on another site and we still get the same results. The number of thread and ramp-up period is both set to 1 to imitate a single user only.
Where a delta exists, it is certain to mean that two different items are being timed. It would help to understand on your front end are you timing to a standard metric, such as w3c domComplete, time to interactive, first contentful paint, some other location, and then compare where this comes into play on the drilldown on the performance tab of chrome. Odds are that there is a lot occuring that is not visible that is being captured by Jmeter.
You might also look for other threads on here on how jmeter operates as compared to a "real browser" There are differences which could come into play affecting your page comparisons, particularly if you have dozens/hundreds of elements that need to be downloaded to complete your page. Also, pay attention to third party components where you do not have permission to test their servers.
I can think of 2 possible causees:
Clear your browser history, especially browser cache. It might be the case you're getting HTTP Status 304 for all requests in browser because responses are being returned from the browser cache and no actual requests are being made while JMeter always uses "clean" session.
Pay attention to Connect Time and Latency metrics as it might be the case the server response time is low but the time for network packets to travel back and forth is very high.
Connect Time. JMeter measures the time it took to establish the connection, including SSL handshake. Note that connect time is not automatically subtracted from latency. In case of connection error, the metric will be equal to the time it took to face the error, for example in case of Timeout, it should be equal to connection timeout.
Latency. JMeter measures the latency from just before sending the request to just after the first response has been received. Thus the time includes all the processing needed to assemble the request as well as assembling the first part of the response, which in general will be longer than one byte. Protocol analysers (such as Wireshark) measure the time when bytes are actually sent/received over the interface. The JMeter time should be closer to that which is experienced by a browser or other application client.
So basically "Elapsed time = Connect Time + Latency + Server Processing Time"
In general given:
the same machine
clean browser session
and JMeter configured to behave like a real browser
you should get similar or equal timings for the same page
Question for LoadRunner TruClient, how to measure page load time properly?
Right now I'm thinking the only way to do is to have 1) Click a link event 2) Verify object show up on the next page.
But if I put the transaction around 1)+2), the response time is really long. If I put the transaction around 2), the response time is really short. I feel it's not accurate measurement of page load time in both ways. What's the proper way to measure page load time? What should I set as the End Event for both steps?
If you are trying to measure client load on the front end the place to begin is in the developer tools long before you get to any sort of multi-user performance test, for any issue you find in the last 100 yards before deployment will have zero chance of going through the page architecture changes required to affect client performance
Example, from Google Chrome, developer tools
I'm load testing a system with 500 virtual users. I've kept the "Ramp-Up period (in seconds)" option to zero. So, what I understand, JMeter will hit the system with 500 virtual users all at the same time. Please correct me if I'm wrong here.
Now, the summary report shows the average response time for the first page is ~100 seconds!. Which is more than a minute and a half of wait time. But while the JMeter is running, I manually went to the same page/url using a browser and didn't have to wait for that long. It was not even close, the page response was almost immediate for me.
My question is: is there any known issue for the average response time of the first page? Is it JMeter which is taking long to trigger that many users?
Thanks in advance.
--Ishtiaque
There is no issue in Jmeter related to first page response time.
Summary Report shows all response time details in Milliseconds, the value "100" seconds have you converted milliseconds to seconds?
Also in order to make sure that 500 users hit concurrently, use Synchronizing Timer.
Hope this will help.
While the response times will be accurate, you need to consider the affect of starting so many threads at once on both your server and your client.
500 threads to start at once is not insignificant n the client. If your server has the connections, it will start 500 threads as well.
Ramping over a period of time is more realistic loadwise, but still not really indicative of server capability until the threads have all started and settled in.
Databases can also require a settling in period which can affect response times.
Alternative to ramping is introducing a random wait at the start of each thread before firing the first sample. You can then choose not to ramp over time, but still expect resources on the client to suddenly come under load and change the settings if you hit limits. This will make the entire run much more realistic of typical behaviour. However, you need to determine if your use cases are typical.
Although the heap size is increased, i notice there is still longer time as compared to actual response time. Later i realised it was the probe effect (the extra time a tool generates due to test execution)
It seems that Chartbeat is reporting my Server Load Time incorrectly.
Does anyone know how Chartbeat measures this data so I can make this metric more accurate?
chartbeat server load time is a measure of how long time it takes to load the HTML from your server, from servers on the east coast US.
http://chartbeat.com/faq/
From Chartbeat: How fast is my site? What information do I get from Load Times?
User Page load
...
It is calculated by timing the two pieces of Chartbeat javascript on the site. This
means it includes all the Javascript and embedded items you have on the page and tells
you how long it's taking to load on the user's browser.
If the load times look incorrect, check to make sure that you have:
<script type="text/javascript">var _sf_startpt=(new Date()).getTime()</script>
In the head of your page before loading your other resources, and the other code they give you just before the body closes.