Gerry Reno wrote: > Right now it's just Apache. The only thing I have to go on is the httpd > access log: > 192.168.2.102 - - [24/Jul/2007:19:59:54 -0400] "GET /gw/ HTTP/1.1" 302 - > 192.168.2.102 - - [24/Jul/2007:19:59:55 -0400] "GET > /gw/login.php?cd=10&forward=%2Findex.php HTTP/1.1" 200 4742 > 192.168.2.102 - - [24/Jul/2007:20:00:50 -0400] "POST > /gw/login.php?forward=%2Findex.php HTTP/1.1" 302 2 > 192.168.2.102 - - [24/Jul/2007:20:01:27 -0400] "GET /gw/index.php > HTTP/1.1" 302 2 > > I just tried to login as another user and it delayed again. And when I > try it directly to the real server I have the same effect so it must be > something with apache. ... After some investigation I think this is an > application problem. It is mainly just one application (the one I was > testing of course) that appears to exhibit this behavior.
This is why I always recommend (and try myself) to use thttpd and a single image and hand coded html page to do initial _and_ ongoing testing. So for instance, I'll run thttpd permanently on port 8088 or something so that if the app is going slow then you can test the timing to the thttpd and see what the response time is vs the "real" application. For initial testing, I use the acme labelmaker http://acme.com/labelmaker/ to create a different gif for each real server with the same name, server.gif And then a simple <html><head></head><body>server X</body></html> html file named server.html or something. That way you can see the effects of the scheduler (rr or whatever) because you'll see "server X" or "server Y" depending on which server you hit but most importantly you don't get hung up with testing a complex multilayer system all at once. I know that Joe uses telnet in the howtos, I find thttpd easier since I can use a browser and can use thttpd to test from outside the firewall, too whereas with telnet I can't. And then once it is basically working, I can use web testing tools to stress test it a bit to check how the LVS/ipvs director, firewall and other parts of the path hold up since generally thttpd will be able to server more request per second than any app server. Later, I save a logo (or some other image) that is used in the live app to the thttpd doc folder, so that I have an apples-to-apples way to compare performance. One nice thing is that then you are testing the same full path all the way to up to the last step - app server vs thttpd. Another is that thttpd is small enough that it can be run (in a testing capacity) on any system without impact on memory or cpu. So then, when someone says "it" is slow, you can quickly identify which part of "it" that is actually slow or not. This is vital if you have different groups responsible for different parts of your systems/networks since it is never their part that is slow and handy for when "nobody" changes "anything" and suddenly performance changes radically. BTW, here is the curlrc file I use to give me a complete breakdown of times for each phase of the web transaction: %<--------------- w = "\t%{http_code}\t%{time_total}\t%{time_namelookup}\t%{time_connect} \t%{time_pretransfer}\t%{time_redirect}\t%{time_starttransfer} \t%{size_download}\t%{size_header}\t%{speed_download}\t%{url_effective}\n" %<--------------- Here is the curl command line I have in cron to monitor changes in web performance: curl -s -S -K /root/.curlrc -o /dev/null http://192.168.2.240/gw/logo.gif >> ./gwtiming.out 2>&1 curl -s -S -K /root/.curlrc -o /dev/null http://192.168.2.240:8088/gw/logo.gif >> ./gwthttpdtiming.out 2>&1 If anyone knows how to get the same level of detail from wget, please let me know. Sorry if this repeats info from past posts/rants... > Rob, Bill, > Got no hits on the tcpdump. > On DNS: no DNS, everything is IP. > > Gerry _______________________________________________ LinuxVirtualServer.org mailing list - lvs-users@LinuxVirtualServer.org Send requests to [EMAIL PROTECTED] or go to http://lists.graemef.net/mailman/listinfo/lvs-users