Is an ISP's geographical location relevant?

[helveticus]

My site is hosted in the US (West Coast). Lately, I noticed
significant loading delays especially in the afternoon (I am currently
located in Belgium/NW Europe). The main page is not exceptionally
heavy on resources (html + CSS + js libraries + images = approx 90K),
yet quite often up to 40s.. 90 s are required to download the page
over DSL, especially in the afternoon.

The main page is essentially pure html (no db access). The ISP
attributes the delay to the fact that the server is busy loading and
re-compiling the application prior to rendering the first page. To
minimize this, they provide the possibility of keeping the app in
server memory against a yearly fee.

I am partially skeptical of their answer. I thought that once ASP
resources were compiled, they'll stay so afterward. But, I also
noticed that some ISP's recognize that delays may be caused by data
being transmitted over long wires. A leading US ASP ISP recently has
decided to open a date-center off-shore (UK) to better serve its
European customers.

Questions:
1. Is ISP server location a relevant argument to explain long
downloads?

2. If yes, is it best to select an ISP close to the intended audience
in order to minimize loading time, avoid traffic congestion etc. or
pay attention to the network? For instance, the pathping tests reveal
that some data lines are significantly lossy at certain periods of the
day (eg. loss rate > 10% on 10 hops out of 18). Or is this only a
marginal consideration?

3. Finally, is there a benchmark that measures the overall time
required to render an application? This yardstick would enable me to
compare performances of the ISP services. TIA.

 

[bruce barker]

there are a lot of issues. you should use a tool to measure download
time (firebug in firefox, dev bar in safari) that times the downloads.
the number of files can make a difference, also caching. check the
latency (need fiddler for this). compare your times to google.

asp.net has a idle timeout the causes it to be unloaded after 20-30
minutes of no use. your isp can change this setting. the next page hit
will cause the site to reload and re-jit (compile). how long this takes
depends on the number of dll's in bin, the number of pages requiring
compile. you can get startup quicker by precompiling the pages to dll's
(but a jit will still be required).


-- bruce (sqlwork.com)

 

[helveticus]

Thanks Bruce. I ran tests on Firebug and Fiddler. Basically, the time-
out bottleneck occurs when calling up the app ie when the default page
loads. Afterward, the app runs smoothly.

I'll try to pre-compile the code to see if this helps. Currently, all
the code resides in the App_Code directory.

Final question: Do you think I should go ahead with their offer and
have the app stay current in the server (I presume this it what it
amounts to.) ? I don't want to be tricked into buying services that
yield no improvement. Thanks.

 

[Cowboy \(Gregory A. Beamer\)]

Going to avoid parroting Bruce here, although I concur with his advice.

My site is hosted in the US (West Coast). Lately, I noticed
significant loading delays especially in the afternoon (I am currently
located in Belgium/NW Europe). The main page is not exceptionally
heavy on resources (html + CSS + js libraries + images = approx 90K),
yet quite often up to 40s.. 90 s are required to download the page
over DSL, especially in the afternoon.

The main page is essentially pure html (no db access). The ISP
attributes the delay to the fact that the server is busy loading and
re-compiling the application prior to rendering the first page. To
minimize this, they provide the possibility of keeping the app in
server memory against a yearly fee.

I am partially skeptical of their answer. I thought that once ASP
resources were compiled, they'll stay so afterward. But, I also
noticed that some ISP's recognize that delays may be caused by data
being transmitted over long wires. A leading US ASP ISP recently has
decided to open a date-center off-shore (UK) to better serve its
European customers.

Assume you mean ASP.NET?

If the worker thread restarts, you can end up with recompilation on pages.
In the config, there are settings for worker thread restart thresholds. In a
corporate owned machine, you normally do not set these too high. This is in
addition to what Bruce mentioned.

Personally, however, I think their answer is probably BS. The extra load
time is experienced on a page by page basis in ASP.NET 2.0+, so a page with
nothing should only take a second, unless you have tons of libraries loaded
with the site.

The lag you are experiencing is more likely having to go across the Atlantic
pipe to get to you in Europe.

Questions:
1. Is ISP server location a relevant argument to explain long
downloads?

Yes, the pipes across the Atlantic are much smaller than the backbone in the
United States and will affect times. How much depends on a variety of
factors, including current load.

2. If yes, is it best to select an ISP close to the intended audience
in order to minimize loading time, avoid traffic congestion etc. or
pay attention to the network? For instance, the pathping tests reveal
that some data lines are significantly lossy at certain periods of the
day (eg. loss rate > 10% on 10 hops out of 18). Or is this only a
marginal consideration?

In general, this is not an issue, but when you are talking cross continent,
it would be useful to have your sites on a box on the same side of the pond,
especially when kids get home and start downloading illegal movies from
Russia. ;-)

3. Finally, is there a benchmark that measures the overall time
required to render an application? This yardstick would enable me to
compare performances of the ISP services. TIA.

There are some test tools for web apps that look at a variety of matrices,
but I am not sure there is one tool that does everything you would need to
properly rule everything out (noisy lines, etc.).