Reference: RidgeStar-Wire Time

RidgeStar utilizes several Linux based Apache web servers inside the RidgeStar world of machines, allowing us to provide extended flexibility and capabilities to our customer sites. One of these capabilities is the internal "Response Time" recording function. To understand how Response time works, take a look at the following figure, which shows an Internet user making a request of a RidgeStar Site from a browser-equipped computer:

The Response Time flow works as follows:

1. The user enters an HTTP request or clicks on a hyperlink that sends a request for information to a RidgeStar hosted site
2. The request travels through the Internet, switching amongst a variety of nodes and routing systems, until it finds its way to a RidgeStar Server
3. The Server accepts the request and schedules it for processing within the Apache HTTP Daemon which, in turn, activates an appropriate script page on the server (.PHP file).
4. Each RidgeStar Site page immediately records the precise time of day that it "starts" to process
5. The appropriate script processing is performed, which may include loading text and/or graphic and performing database input and output operations.
6. After the page (.PHP file) performs all of the requested functions, it again records the precise time of day that it "ends" processing the request
7. The server's response is then routed back through the maze of Internet servers, routers, and switching equipment, until the requested information is displayed on the user's Browser

Response Time

The Response Time is available on your site (normally, in the Administrator: Operations area). It is the wall clock length of time a request was active within the Server (identified as "Server Processing" in the graphic). It is NOT CPU time, but wall clock time. Further, it does NOT include any elapsed time where the request (either coming or going) is being routed through the Internet.

We use the following terms to communicate with our clients on performance related questions:

Response Time

The elapsed wall clock time that a single page on the Server took to process a single HTTP page request. This WILL include any elapsed time associated with database input and output operations, etc. to produce the resulting page

Wire Time

The elapsed wall clock time associated with Internet routing of the request from the Visitor's keyboard to the Server and, similarly, from the Server back to the Visitor's display

The Good, Bad, and the Ugly

So, how should you interpret this information when you experience response or performance problems with your site?

The Good

If the Response Time is long (e.g. consistently more than a few seconds), as reported by the Administrator: Operations area, contact your Account Representative and ask that we look into poor performance on your site

The Bad

If the Response Time is short (e.g. 0.0321 seconds) but the length of time you're actually waiting is 30 seconds or more, the problem is in the "Wire Time" and we (RidgeStar) cannot fix it or even affect it very much. (We wish we could, but ... no one has put us in charge of general Internet performance and bottleneck diagnosis yet...).

The Ugly

And even worse, there is nowhere we (or you) can call to immediately "fix it". The problem is likely a bottleneck or an outage within the routing equipment that comprises the Internet. We mostly have to hope that whoever is experiencing the difficulty will notice it and fix it.

You can do things like find out if all or only some sites across the Internet are similarly slow. If all sites are slow, it could indicate that your Internet Access Provider or even your own system has a problem. If only some sites are slow, it could indicate that a specific switch or vendor's backbone connection is broken or operating poorly. Use your imagination to help diagnose the issue and contact the right people.

Remember, the Internet works by all of us communicating and working effectively together.