What kind of response time can I expect?
Peter Olcott
application.
It must have a maximum of a 1/2 second response time, 1/10
second would be much better.
It will have 10K bytes input and 30 bytes of output.
Can I reasonable expect to get this response time?
Is the response time the sum of the latency (determined by
ping) plus the bandwidth?
If this is true then, 35 MS latency + 256 mb bandwidth would
then derive about 1/2 second response time.
AliR
a good formula.
Lets assume that the server you are hitting is not busy, and that the ISP
you are using to go out is not flooded at that moment. (which are two major
factors if you ask me).
Then you have to see how long it takes the web service you are using to do
it's thing, and attempt to send the results back.
The main thing is that if this is going to run on a WAN then there is not
guarantee that any of your calculation will be accurate at any one time.
AliR.
"Peter Olcott" <NoS...@SeeScreen.com> wrote in message
news:nY2dnYm1Heudum_X...@giganews.com...
Joseph M. Newcomer
On Wed, 4 Nov 2009 19:14:40 -0600, "Peter Olcott" <NoS...@SeeScreen.com> wrote:
>I am trying to determine the feasibility of a web
>application.
>It must have a maximum of a 1/2 second response time, 1/10
>second would be much better.
>
>It will have 10K bytes input and 30 bytes of output.
****
10K bytes at what bandwidth? Do you measure time from start-of-transmit-at-client to
end-of-receipt-of-reply-at-client, or from end-of-receive-at-server to
start-of-transmit-response-at-server? Or from click-of-button-at-client to
end-of-rendering-of-response-at-client?
Note that the only value you have any control over is the end-of-receive-at-server to
start-of-transmit-response-at-server. The rest is up to the network routers. This is why
when you get a Google response that says it took 0.1 seconds, you may have waited 5
seconds to get it.
****
>Can I reasonable expect to get this response time?
****
Maybe. Since we don't know what you mean by "response time" we can't really tell. You
have not explained what you need to do with the data. Query a database? Run an FFT over
it? Complement every other bit and send back a checksum?
****
>Is the response time the sum of the latency (determined by
>ping) plus the bandwidth?
****
Definitely not. Latency measures one tiny and uninteresting piece of the world: the time
to turn a ping around. It does not take into consideration a two-way TCP/IP protocol with
transmission, response, buffer management, creation of a receiving socket, handshaking,
etc. There may be a large number of round trips of data to establish a TCP/IP connection,
and it may take, for 10,000 bytes, 20 or more packets to transmit. Since the transmission
delay is entirely out of your hands, being the responsibility of the network stacks at the
sender and receiver, and any routers, there's not a lot you can do about that.
****
>
>If this is true then, 35 MS latency + 256 mb bandwidth would
>then derive about 1/2 second response time.
****
How? You have not given your network speed, so there's no way to tell how you got this
number; as I said, a 10K upload will require about 20 transmissions, but with a sliding
window protocol (which is most commonly used) they may be overlapped in unusual ways so
there is no known way to correlate the ping time with anything else.
Note that the ping time also includes the response time of the recipient.
There is no way to guarantee the response time once you go across a router. With a 35ms
ping time, you are not local (local pings run under 5ms and sometimes 1ms), so you have no
control over how the transmission happens. The size of the sliding window depends on the
size specifications given for the transmission to the recipient and is a dynamic value.
There is no simple arithmetic formula that is going to give you a single number. And the
ping time is going to be among the least interesting of the values you use.
joe
****
>
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Peter Olcott
"Joseph M. Newcomer" <newc...@flounder.com> wrote in
message news:m806f5p91mng0reob...@4ax.com...
It seems that I am asking for a probability distribution.
For example the arithmetic mean of 0.35 seconds with a
standard deviation of 0.2 seconds.
I may have to derive these empirically, but, then that
requires the steep learning curve that may be all for
naught.
Joseph M. Newcomer
****
If you derive it empirically between machine A and machine B, that value applies only for
the time you did the experiiment. Tomorrow, an hour from now, ten minutes from now, it
may all change (if, in the next hour, there is some amazingly newsworthy event, everyone
is going to be swamping all the routers). It may be different if machine B is in a
different time zone; note that loads have multimodal local distributions (right before
leaving for work; at lunchtime; after work; after dinner).
The only time you can ever control is the after-receipt-of-packet-to-start-of-next-send
interval. After that, it is out of your control. No matter what you *want*, you will get
whatever the network routing delivers
For example, my basic support comes from verizon.net (my ISP is another site entirely), so
I can do
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\email>ping verizon.net
Pinging verizon.net [206.46.232.39] with 32 bytes of data:
Reply from 206.46.232.39: bytes=32 time=54ms TTL=245
Reply from 206.46.232.39: bytes=32 time=52ms TTL=245
Reply from 206.46.232.39: bytes=32 time=51ms TTL=245
Reply from 206.46.232.39: bytes=32 time=52ms TTL=245
Ping statistics for 206.46.232.39:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 51ms, Maximum = 54ms, Average = 52ms
C:\Documents and Settings\email>tracert verizon.net
Tracing route to verizon.net [206.46.232.39]
over a maximum of 30 hops:
1 1 ms 1 ms 1 ms 192.168.1.1
2 6 ms 5 ms 6 ms L101.PITBPA-VFTTP-06.verizon-gni.net [173.75.35.1]
3 6 ms 6 ms 6 ms 130.81.178.154
4 52 ms 51 ms 52 ms P5-0-0.PITBPA-LCR-03.verizon-gni.net [130.81.27.250]
5 12 ms 12 ms 13 ms so-15-3-0-0.LCC1-RES-BB-RTR1-RE1.verizon-gni.net
[130.81.28.204]
6 51 ms 51 ms 51 ms so-4-0-0-0.DFW01-BB-RTR1.verizon-gni.net [130.81.17.41]
7 52 ms 51 ms 51 ms so-1-0-0-0.DFW03-CORE-RTR1.verizon-gni.net [130.81.20.157]
8 52 ms 51 ms 52 ms po1.ctn-border1.vzlink.com [206.46.225.85]
9 52 ms 51 ms 52 ms po121.ctn-core1.vzlink.com [206.46.225.18]
10 52 ms 52 ms 51 ms 206.46.228.130
11 53 ms 51 ms 52 ms 206.46.232.39
Trace complete.
C:\Documents and Settings\email>
Note that it takes 11 hops to get to the actual verizon.net site! And consider:
C:\Documents and Settings\email>tracert google.com
Tracing route to google.com [74.125.53.100]
over a maximum of 30 hops:
1 3 ms 1 ms <1 ms 192.168.1.1
2 6 ms 5 ms 6 ms L101.PITBPA-VFTTP-06.verizon-gni.net [173.75.35.1]
3 6 ms 7 ms 5 ms G2-0-8-345.PITBPA-LCR-03.verizon-gni.net [130.81.178.30]
4 13 ms 77 ms 13 ms so-15-3-0-0.LCC1-RES-BB-RTR1-RE1.verizon-gni.net
[130.81.28.204]
5 13 ms 12 ms 43 ms 0.so-1-2-0.XL3.IAD8.ALTER.NET [152.63.37.117]
6 13 ms 13 ms 13 ms 0.xe-9-0-0.BR1.IAD8.ALTER.NET [152.63.41.49]
7 76 ms 20 ms 20 ms te-10-1-0.edge1.Washington4.level3.net [4.68.63.245]
8 20 ms 32 ms 25 ms vlan99.csw4.Washington1.Level3.net [4.68.17.254]
9 19 ms 19 ms 19 ms ae-92-92.ebr2.Washington1.Level3.net [4.69.134.157]
10 34 ms 34 ms 34 ms ae-2-2.ebr2.Chicago2.Level3.net [4.69.132.69]
11 34 ms 34 ms 34 ms ae-1-100.ebr1.Chicago2.Level3.net [4.69.132.113]
12 70 ms 71 ms 71 ms ae-3.ebr2.Denver1.Level3.net [4.69.132.61]
13 89 ms 89 ms 89 ms ae-2.ebr2.Seattle1.Level3.net [4.69.132.53]
14 84 ms 86 ms 83 ms ae-2-52.edge1.Seattle3.Level3.net [4.68.105.44]
15 107 ms 83 ms 84 ms GOOGLE-INC.edge1.Seattle3.Level3.net [4.59.232.34]
16 84 ms 83 ms 84 ms 209.85.249.34
17 132 ms 93 ms 88 ms 209.85.250.126
18 90 ms 89 ms 90 ms 216.239.48.34
19 90 ms 184 ms 90 ms 64.233.174.121
20 92 ms 89 ms 90 ms 72.14.232.10
21 90 ms 90 ms 90 ms pw-in-f100.1e100.net [74.125.53.100]
Trace complete.
C:\Documents and Settings\email>
21 hops to google.com.
Your Mileage May Vary.
You can make no guarantees other than guaranteeing your own internal response time. After
that, you have absolutely no control, ever.
Note the reponse times vary; for example hop 8 took 25ms to respond, but hop 9 took 19ms
to respond! Hop 13 took 89ms, but a fraction of a second later, hop 14 took 83ms.
It has often been said that the greatest delays and least predictability is in "the last
mile", that is, the low-bandwidth link to your computer (unless you have a direct 2.5GB
backbone, or one of the new 10GB backbones, you have low bandwidth to your computer!) That
can vary a lot; if you are on a cable TV Internet service, they might throttle it based on
movie downloads, or on-demand movies that everyone on your block might be watching. One
of the great controversies is that some will throttle the bandwidth based on your most
recent history. Commercial systems which implement QOS (Quality of Service) sometimes
have lower variance, but they are expensive.
Note that all these numbers are for single-packet transfers. Once you get into TCP/IP,
buffer management, sliding-window protocols, etc., you can *only* measure it empirically
at the client site (to get client-start-to-server-reply times) and to get anything
reliable, you have to plot it at various times of day, on various days, and you might get
a sample that is statistically significant after a month of measurements. I have a friend
who worked for many years with a company that actually did this for a living; they would
instrument the network for a Fortune x00 company and compare Verizon to Sprint to whatever
and evaluate vendors based on measured bandwidth. Ultimately, the company went out of
business because the variations were too wide to reliably compare service A with service B
at all times of day, under all scenarios (suddenly, everyone is going for a google term or
a YouTube video, and the bandwidth of the major cross-country backbones is saturated, for
a couple days).
joe