Thanks for your reply. I'll do my best to answer your questions below. > > ipA [31/Mar/2011] "GET /file.jpg HTTP/1.0" 200 42981 > "-" "ApacheBench/2.3" 3560 > > ipB [31/Mar/2011] "GET /file.jpg HTTP/1.0" 200 42981 > "-" "ApacheBench/2.3" 93574 > > > > (the ipA is much "closer" to the server than ipB). > > First, are these results consistently repeatable over a > large number of measurements? If not, then it is > likely just normal statistical variation due to normal > network traffic, CPU scheduling, or something similar. > Otherwise...
apache log gives numbers in the ranges 3000-4000 vs. 80000-120000 so I'd say they are consistent. (running ab -c 1 -n 100 ) > What does 'much "closer"' mean? The server is in Amazon EC2 cloud, and ipA is another EC2 instance. ipB is from the office, and ab reports a noticeble difference in latency, about 43 ms when accessing from ipB. > What is the hardware (number and speed of CPUs, amount of > RAM, etc.) for ipA and ipB? What OS and version are > each running? How heavily loaded is each one during > the test (CPU, I/O)? How is the kernel and networking > stack on each one configured? There is almost zero load on the machines. The EC2 machines are small instances (1 core each) and the office machine a common PC with two cores. They are all running Ubuntu Linux (LTS 10.04 in EC2) and 10.10 in office PC. I'm not sure how to answer about the kernel and networking stacks. > I recommend using a network sniffer to analyze differences > in network traffic for a request sent from ipA versus a > request sent from ipB. Try and find out where the > delay is occurring for ipB. I will try to do that. > If (and only if) the network trace shows that the delay is > in waiting for your server to generate and send packets to > ipB -- as opposed to your server waiting for packets from > ipB -- then use performance analysis tools on your server > such as strace, truss, DTrace, or SystemTap to figure out > what your kernel, and web server processes are doing during > that time. > > Keep in mind that you're looking at a 90 millisecond > (90,000 microsecond) difference between the two > clients. Depending on your situation, this may or may > not actually be a significant real-world problem, and hence > it may or may not justify a large amount of time and effort > for finding the cause. > > > > > i also tried a curl download with a limit on 1000 > bytes/s but the time logged in access-log many orders of > magnitute away from the acctual time it took to receive the > image (about 42 seconds) So I guess the time that is logged > is "when apache has sent the final bytes to the level below > in the network stack? > > %D measures how long Apache spends processing the > request. It does not measure how long other things on > your server (kernel, host-based firewall, etc.) take to > process the data, nor does it measure how long it takes data > to actually reach the client. If you are interested in > how long the request takes on the client (including how long > it takes the response to travel from the server to the > client), then you will need to measure that on the client, > not on the server. On the client side the speed difference is a factor of not 30 as above but more like 60 or even more. --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org " from the digest: users-digest-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
