I have large time to first byte for static content on IIS 7.5, it's not site specific it's slow for all sites on that server. runAllManagedModulesForAllRequests is set to false, and gzip is enabled for static content. How can I troubleshoot this problem ?
Here are the timings, time to first byte for fairly complex ASP.NET site is 368 ms, and for just grabing css file is 617 ms !! That time is different every time but still too much, not below 200 ms that seems way too much for such task.
Server has plenty free memory (in this moment more than 7 GB).
Does it happen every time?
Is compression turned on for the static object, what level is it set to and is the compressed version being cached on the server?
What's the CPU load like?
Does it happen for all static content or just css?
Related
For a very simple application, my Meteor site is taking 4.1s to start downloading the first byte of data. This is with a very basic setup. The relevant times etc (taken from http://www.webpagetest.org) are:
IP: 107.22.210.133
Location: Ashburn, VA
Error/Status Code: 200
Start Offset: 0.121 s
DNS Lookup: 64 ms
Initial Connection: 56 ms
Time to First Byte: 4164 ms
Content Download: 247 ms
Bytes In (downloaded): 0.9 KB
Bytes Out (uploaded): 0.4 KB
Is this due to Meteor being slow, or is there likely to be a bottleneck in my code? Is there a way to determine this?
Thanks.
That delay is a function of the time it takes your subscriptions to get data from the server. If any of the document data the client needs on page load is static, store it in unmanaged (unsynchronized) local collections so it is available immediately on initial page load. See collections.meteor.com for a load time comparison of data stored in an unmanaged versus a managed collection.
According to webpagetest, that's:
the time needed for the DNS, socket and SSL negotiations + 100ms.
I loved the #ram1's answer, but I would like to add that it's also due to your server performance. That amount of time is common in shared hostings. There are two workarounds there: change your hosting or add a CDN service.
Also, it will help if you have less redirections.
You should make a better use of cache and, for Chrome users, you can apply the pre- party features.
I'm using Nopcommerce 2.40.
I've run load test with 5 virtual user for 1 min on ErrorPage.htm which is simple HTML page and found that..It is taking 25 to 35% of CPU.
I think it is going to be serious performance problem if simple HTML is taking too much CPU.There is no need to check other pages and it does not matter whether you are using Output caching or other caching to improve performance.
What could be the reason behind this?
It executes several SQL commands. There is a fix available here:
http://nopcommerce.codeplex.com/SourceControl/changeset/changes/f693be2bc2e0
This will add htm and html pages to ignore.
My English is not good and I find it really difficult to explain to everybody but please try to read it anyway.
I have a website with a big database. My site lost a lot of time to load page although google for 94/100 (https://developers.google.com/pagespeed/#url=5sonly.com_2Findex.php_3Fmain__page_3Dsearch_26keyword_3Dshirt_26slctbxsb_3D2_26slctbxshppngt_3D223_26page_3D132&mobile=false). I had optimized all content, database and used cache technology but time for the first byte is not good. Example:
When you try to click this link:
http://www.5sonly.com/index.php?main_page=search&keyword=shirt&slctbxsb=2&slctbxshppngt=223&page=132
You will have to wait a long time to the page load.
I had used index/fulltext for the search page but I dont know why my site is still very slow (more 24 seconds).
How can I do to optimize for the first byte time. I can provide all information if you request. Please let me know.
P/S: I have currently disabled cache to you can test better.
I think you are doing heavy calculation at server side so it responds slow,
you can see in image some resource take 7 to 13 seconds to load,
this cause your loading slow.
I am measuring page rendering speed, firing a StopWatch at OnBeginRequest, and stopping it at OnResultExecuted, thereby measuring the entire page render cycle.
I get the following time stamps during rendering:
0 ms - OnBeginRequest
+1.1 ms - OnActionExecuting
+2 ms - OnActionExecuted
+3 ms - OnResultExecuted
the three latter timestamps are of course application-specific, but I am wondering what happens during the 1.1 millisecond between the moment the app receives the request and the action method gets control?
How to reduce this time?
What is the maximum rendering speed you ever obtained with MVC.NET (pages per second) and how did you do it?
Many things happen: routes are parsed, controller is located and instantiated, action method is called. Make sure that you are running in Release mode:
<compilation debug="false" />
so that your measurement results are more realistic. In reality the time between receiving the request and invoking the controller action is never a bottleneck. It is the time spent inside the controller action that you should focus on reducing. This is where your application might gain a real performance boost. There are different techniques for improving performance and a popular one is to use caching.
According to Gu:
Today’s ASP.NET MVC 3 RC2 build
contains many bug fixes and
performance optimizations. Our latest
performance tests indicate that
ASP.NET MVC 3 is now faster than
ASP.NET MVC 2, and that existing
ASP.NET MVC applications will
experience a slight performance
increase when updated to run using
ASP.NET MVC 3.
Time taken to render a page is different to number of requests per seconds are not directly correlated values (similar to FPS and time per frame in game development see here). Especially in a multi-threaded environment.
Personally on my machine an empty MVC applications renders the default controller and view in 0.8-1.1 ms. Of course the route collection is almost empty, so that presumably saves a lot of time. There are a few optimizations you can make, you can find them on the net easily, one of the primary ones is: clear your view engines and add just the view engine you are using, that will save a roundtrip to the hard drive on every request.
ViewEngines.Clear();
ViewEngines.Engines.Add(new WebFormViewEngine()));
As for real websites I was able to get a real world MVC application to render more than 2000 requests per second. One thing you might want to try is to put your Temp ASP.Net files and your website folder on a RAM drive, since MVC and IIS do hit the physical assembly file on every request, but realistically the gain is too small to be noticeable or worth anyone's time.
If you look at the source code here page generation time is at 1 ms (this is not entirely true since it's in the middle of the view, but very close nevertheless). That server is running on a RAM drive. You can speed it up a little bit more by moving ASP.Net Temp Files to a RAM drive, but I couldn't get it under 0.8 ms no matter what.
Website Page load times on the dev machine are only a rough indicator of performance of course, and there will be many other factors when moving to production, but they're still useful as a yard-stick.
So, I was just wondering what page load times you aim for when you're developing?
I mean page load times on Dev Machine/Server
And, on a page that includes a realistic quantity of DB calls
Please also state the platform/technology you're using.
I know that there could be a big range of performance regarding the actual machines out there, I'm just looking for rough figures.
Thanks
Less than 5 sec.
If it's just on my dev machine I expect it to be basically instant. I'm talking 10s of milliseconds here. Of course, that's just to generate and deliver the HTML.
Do you mean that, or do you mean complete page load/render time (html download/parse/render, images downloading/display, css downloading/parsing/rendering, javascript download/execution, flash download/plugin startup/execution, etc)? The later is really hard to quantify because a good bit of that time will be burnt up on the client machine, in the web browser.
If you're just trying to ballpark decent download + render times with an untaxed server on the local network then I'd shoot for a few seconds... no more than 5-ish (assuming your client machine is decent).
Tricky question.
For a regular web app, you don't want you page load time to exceed 5 seconds.
But let's not forget that:
the 20%-80% rule applies here; if it takes 1 sec to load the HTML code, total rendering/loading time is probably 5-ish seconds (like fiXedd stated).
on a dev server, you're often not dealing with the real deal (traffic, DB load and size - number of entries can make a huge difference)
you want to take into account the way users want your app to behave. 5 seconds load time may be good enough to display preferences, but your basic or killer features should take less.
So in my opinion, here's a simple method to get a rough figures for a simple web app (using for example, Spring/Tapestry):
Sort the pages/actions given you app profile (which pages should be lightning fast?) and give them a rough figure for production environment
Then take into account the browser loading/rendering stuff. Dividing by 5 is a good start, although you can use best practices to reduce that time.
Think about your production environment (DB load, number of entries, traffic...) and take an additional margin.
You've got your target load time on your production server; now it's up to you and your dev server to think about your target load time on your dev platform :-D
One of the most useful benchmarks we use for identifying server-side issues is the "internal" time taken from request-received to response-flushed by the web server itself. This means ignoring network traffic / latency and page render times.
We have some custom components (.net) that measure this time and inject it into the HTTP response header (we set a header called X-Server-Response); we can extract this data using our automated test tools, which means that we can then measure it over time (and between environments).
By measuring this time you get a pretty reliable view into the raw application performance - and if you have slow pages that take a long time to render, but the HTTP response header says it finished its work in 50ms, then you know you have network / browser issues.
Once you push your application into production, you (should) have things to like caching, static files sub-domains, js/css minification etc. - all of which can offer huge performance gains (esp. caching), but can also mask underlying application issues (like pages that make hundreds of db calls.)
All of which to say, the values we use for this time is sub 1sec.
In terms of what we offer to clients around performance, we usually use 2-3s for read-only pages, and up to 5s for transactional pages (registration, checkout, upload etc.)