I've been noticing really long load times on my website (www.randomaccessit.com) and also long load times or even time-outs on my email (using Windows Live Mail). I use both on multiple computers at different locations so I know it's not my equipment here. Could I just be far away or using a crappy route to access your servers or is it possible to do some basic performance diagnostics on my hosting? If there's any IIS7 tweaks that should be made I'll be happy to do that. I doubt my website is coded for poor performance (it's basic ASP.NET, nothing too fancy), but I'm definitely open to the possibility. Pinging the server returns on average 128ms (whereas google returns around 40ms). I'm using Comcast in Vermont, USA. I'd be happy to provide traceroutes and other diagnostic info maybe in a less public area. Thanks ahead of time for any suggestions/help.
Its hard to say. Even if you use two different computers at different networks may ultimately be misleading. For example if you are at the UK, the main network bridge between UK and the US maybe suffering from a disruption. The next best step is to perform a traceroute and pathping test to your domain name. If you post the results we can review them together.
Hope this helps. Looks like my times skyrocket when they get to Los Angeles. TraceRoute: Code: C:\Users\RandomAccess>tracert www.randomaccessit.com Tracing route to www.randomaccessit.com [96.31.35.33] over a maximum of 30 hops: 1 1 ms 1 ms 2 ms 192.168.10.1 2 * * * Request timed out. 3 9 ms 9 ms 8 ms ge-5-3-ur01.milton.vt.boston.comcast.net [68.87. 150.149] 4 11 ms 10 ms 11 ms te-8-2-sr01.derby.vt.boston.comcast.net [68.85.3 7.206] 5 13 ms 13 ms 13 ms te-9-2-ur01.berlin.vt.boston.comcast.net [68.87. 146.217] 6 23 ms 20 ms 21 ms be-70-ar01.needham.ma.boston.comcast.net [68.85. 69.177] 7 28 ms 27 ms 26 ms pos-2-2-0-0-cr01.newyork.ny.ibone.comcast.net [6 8.86.93.185] 8 28 ms 29 ms 28 ms pos-1-6-0-0-pe01.111eighthave.ny.ibone.comcast.n et [68.86.87.110] 9 26 ms 27 ms 28 ms er2-tengig3-3.newyork.savvis.net [208.173.138.13 ] 10 27 ms 28 ms 28 ms cr1-tengig-0-8-3-0.NewYork.savvis.net [204.70.19 8.13] 11 117 ms 116 ms 115 ms cr1-pos-0-0-3-3.losangeles.savvis.net [204.70.19 2.138] 12 118 ms 118 ms 124 ms hr2-te-1-0-0.elsegundola1.savvis.net [204.70.203 .89] 13 118 ms 117 ms 116 ms hr1-te-1-0-1.elsegundola1.savvis.net [204.70.203 .69] 14 116 ms 117 ms 116 ms hr2-te-1-0-0.irvine2oc2.savvis.net [204.70.204.1 93] 15 117 ms 116 ms 118 ms hr1-te-1-0-1.irvine2oc2.savvis.net [204.70.204.1 65] 16 118 ms 116 ms 117 ms 64.79.173.6 17 118 ms 118 ms 118 ms 96-31-33-196.hostcollective.com [96.31.33.196] 18 117 ms 119 ms 118 ms 96-31-33-227.hostcollective.com [96.31.33.227] 19 119 ms 118 ms 118 ms w03.Winhost.com [96.31.35.33] Trace complete. C:\Users\RandomAccess> PathPing: Code: C:\Users\RandomAccess>pathping www.randomaccessit.com Tracing route to www.randomaccessit.com [96.31.35.33] over a maximum of 30 hops: 0 ra-frontdesk [192.168.10.103] 1 192.168.10.1 2 * * * Computing statistics for 25 seconds... Source to Here This Node/Link Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address 0 ra-frontdesk [192.168.10.103] 0/ 100 = 0% | 1 1ms 0/ 100 = 0% 0/ 100 = 0% 192.168.10.1 Trace complete. C:\Users\RandomAccess>
As an example, my email client just informed me (twice in a row) that my email imap server did not respond within 60 seconds. This happens from time to time but more frequently lately. For email: Code: C:\Users\RandomAccess>tracert mail.randomaccessit.com Tracing route to mail.randomaccessit.com [64.79.170.146] over a maximum of 30 hops: 1 6 ms 1 ms <1 ms 192.168.10.1 2 * * * Request timed out. 3 104 ms 10 ms 9 ms ge-4-3-ur01.milton.vt.boston.comcast.net [68.87. 150.145] 4 12 ms 12 ms 38 ms te-8-2-sr01.derby.vt.boston.comcast.net [68.85.3 7.206] 5 128 ms 14 ms 13 ms te-9-2-ur01.berlin.vt.boston.comcast.net [68.87. 146.217] 6 25 ms 19 ms 19 ms be-70-ar01.needham.ma.boston.comcast.net [68.85. 69.177] 7 29 ms 40 ms 26 ms pos-2-1-0-0-cr01.newyork.ny.ibone.comcast.net [6 8.86.95.29] 8 29 ms 27 ms 41 ms pos-0-3-0-0-pe01.111eighthave.ny.ibone.comcast.n et [68.86.85.18] 9 29 ms 28 ms 26 ms er2-tengig3-3.newyork.savvis.net [208.173.138.13 ] 10 27 ms 28 ms 29 ms cr2-tengig-0-15-4-0.NewYork.savvis.net [204.70.1 98.17] 11 125 ms 125 ms 129 ms cr1-pos0-3-2-0.losangeles.savvis.net [204.70.197 .41] 12 127 ms 125 ms 126 ms hr2-te-1-0-0.elsegundola1.savvis.net [204.70.203 .89] 13 126 ms 126 ms 126 ms hr1-te-1-0-1.elsegundola1.savvis.net [204.70.203 .69] 14 132 ms 125 ms 129 ms hr2-te-1-0-0.irvine2oc2.savvis.net [204.70.204.1 93] 15 129 ms 127 ms 127 ms hr1-te-1-0-1.irvine2oc2.savvis.net [204.70.204.1 65] 16 126 ms 129 ms 127 ms 64.79.173.6 17 128 ms 127 ms 137 ms 96-31-33-196.hostcollective.com [96.31.33.196] 18 135 ms 126 ms 128 ms 96-31-33-227.hostcollective.com [96.31.33.227] 19 128 ms 126 ms 127 ms m02.internetmailserver.net [64.79.170.146] Trace complete. C:\Users\RandomAccess>
A few things; first, when you traceroute to Google, you are connecting to a server near you, not on the other side of the country, as is the case when you traceroute to your site here in Los Angeles. So "Pinging the server returns on average 128ms (whereas google returns around 40ms)" is not really an apples to apples comparison. I wouldn't necessarily characterize 125ms as "skyrocketing." That's not a tremendously impressive response time, but it isn't in the realm of ah-ha-there's-your-problem. You would expect to see short hops on local Comcast networks in comparison to what you see when you leave their borders. All of this is to say that while traceroute is a useful tool, you are not always going to find the source of your problems with it. Bear in mind that pretty much every Tier1 ISP (like savvis.net) uses closest-exit routing which creates a lot of asymmetric routes. What that means is your traffic to our server here is probably coming back to you on a completely different route, and your traceroute only shows one direction: from you to us. Your pathping looks like it's never leaving your local network...it should include the entire path of a regular traceroute.
Fair enough. I understand that 125ms isn't all that slow but something is. I thought I'd start at the wire and work up from there to figure out why my site and email are so slow. I have a feeling it's either an IIS7 setting, use of database connectivity on the homepage, or the ASP.NET code itself that are causing the high load times. I have no idea why the e-mail is so slow that it times out.
Just stumbled on this post and wanted to agree. I just recently moved a domain over to Winhost and yes my experience is it's slow. Best speed I could get transfering files to/from was 1.4 mb (yes that's megabit) and just signing up to post on this forum, it took 19 minutes to get the activation email to post! Not looking to make / start a beef cause basically the facility that is offered for the price is quite good. But gawd, I haven't used something this slow since my ISDN days. Is there an *upgrade* option to assure better bandwidth?
The forum sends out email on scheduled task intervals (every 10 minutes for more common things), not immediately after you sign up. There is not a "bandwidth upgrade." To offer such a thing would mean that we are purposely providing substandard service by default, and that's not the case. As we've been over in the thread here (and others), there are a lot of factors that contribute to the speed you experience.
I've been exploring some IIS7 tweaks and DNN tweaks to help ease the very slow load times but nothing has made a significant difference. I understand that the connection isn't terrible but I would still like a little help finding insight as to why the slow load times are happening. Is there any tweaks I should be doing in DNN/IIS7 that you are aware of or that I could try? Nearly 5 seconds to load the homepage is a bit harsh when showing it to clients.
No not really. Thats seems how DNN works. Rather then trying to reinvent the wheel per say maybe you should consider using another CMS application.
I think it's time for me to resurrect this thread. I'm still experiencing very slow loading times (not just by me but from friends around the USA). I'm not using DNN, it's my own ASP.NET code (not even that much of it either). I have other sites with you guys as well that I'm working on (voltagesportsclub.com, mysticfarmsartwork.com) and they all load very slow. Recently I've been forced to sign up a few new clients on an alternate host because the loading times were unacceptable for them. One is running Orchard and the other is using Wordpress (so ASP.NET is not the issue). I fear that if I can't find a resolution to this problem that I will be forced to use alternate hosts for future clients.
I took a quick look at both sites (voltagesportsclub.com and mysticfarmsartwork.com), but I didn't notice any problems. mysticfarmsartwork.com was slow at first, but that's due to first time application recompile. Subsequent visits seemed normal to me.
Well for the two sites you mentioned at the end I can't get onto voltagesportsclub.com because it leads me to directory browsing which I suggest you disable anyway but I believe that is because you have no default page in the root. Mystic Farms Artwork is strangely slow at first but I agree with Elshadriel that it is the application recompile that seems to take time which suggests something is wrong with your code, try only loading essential components at first then load the rest in the background. As for Random Access IT, connecting to the page is fast but downloading the site is slowish because none of the images on your site are compressed properly. All of this and I live in Australia, I have no issue with my site however email is a "bit" slow "sometimes" but I don't need my emails every second, a few seconds delay isn't the end of the world.
General slowness with email and website I concur with the original post - my ASP.NET website hosted on Winhost is awfully slow to load. HTML pages load fine, but ASP.NET MVC pages take on average about 3-5 seconds to load (sometimes 8-9 seconds). I'm viewing my website from London so I would have thought there would be a decent routing for a major European city to the Winhost servers. This is not practical for any website made for public use, especially in e-commerce. My email have sometimes been delayed too, but that's less of a priority. I don't think the servers are good enough for running anything more complex than static HTML pages. I will be looking for another hosting company and paying a bit more for faster page loading. On the other hand, the customer support has been speedy and useful for me. And it's low cost, so ideal for someone who wants to test a ASP.NET web application in a staging environment.
Well that's a thorny issue, isn't it, since we don't control the routes to and from our servers. Latency due to distance is a difficult thing to get people to accept. But there's nothing anyone can do about it. Until they invent some sort of ozone-based Internet backbone (probably coming in 2015). But even that would have some latency. If you're in Europe and most of your customers are in Europe, then I wouldn't disagree with you that servers in California may not be the optimal solution for you. If your customers are all over the world, as is more and more common these days, then if you're serving your site from a single location, the U.S. isn't a bad choice. It's different for everyone.
I think it's not just the route to the server. It seems to be mainly to do with the actual server processing ASP.NET pages. As I've mentioned, static HTML pages (with lots of content and images) load fine. ASP.NET pages (with a small proportion of dynamic content) takes anywhere between 3-9 seconds to load. All the website is doing is querying a SQL Server DB for 5 items and display the results in a few lines of text.
You don't mention your domain name, so it's difficult to assess any problems you might be having. But generally speaking, there isn't much value in a comparison between a static page and something like a .NET application that uses a database. The .NET framework and SQL server introduce overhead (and a large number of other variables that can affect responsiveness) that a static page isn't burdened with. Even to display a few lines of text. But again, you're working with servers that are on the other side of the world, so you may have a better overall experience with a host that's geographically closer to you. Or you may not. It depends on a lot of different factors.
