This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Subject: Re: Does mod_perl have anything to do with KeepAlive? From: David Hodgkinson <daveh@hodgkinson.org> Date: 28 Nov 2000 10:15:51 +0000 Larry Leszczynski <larryl@furph.com> writes: > Hi All - > > I'm hoping for some enlightenment about how KeepAlive is implemented in > Apache and whether KeepAlive even comes into play when front-end and > back-end mod_perl servers communicate with each other via HTTP. http://thingy.kcilink.com/modperlguide/performance/KeepAlive.html === Subject: Re: Does mod_perl have anything to do with KeepAlive? From: Larry Leszczynski <larryl@furph.com> Date: Tue, 28 Nov 2000 07:41:27 -0500 (EST) Hi All - > I'm hoping for some enlightenment about how KeepAlive is > implemented in Apache and whether KeepAlive even comes > into play when front-end and back-end mod_perl servers > communicate with each other via HTTP. I suppose I shouldn't have started off my previous post with such a general-sounding comment. Thanks for all the pointers to the KeepAlive section in the mod_perl guide, which I have read before and which doesn't answer the questions I was asking below. I'll try rephrasing, I'm still hoping for info regarding the questions that follow: mod_backhand takes advantage of KeepAlive to speed up communications between a front-end server and a set a back-end servers that feed data to the front-end. I'm trying to figure out how that works and if I can take advantage of KeepAlive the same way using mod_perl front-end and back-end servers but without running mod_backhand. Suppose front-end server A is handling user requests. In the process of handling a front-end request, suppose I use LWP or equivalent to make a HTTP request from A to a back-end server B to get some data that is needed. Assuming all the right headers are set for KeepAlive to work (content length, etc.), can the connection between A and B even take advantage of KeepAlive for the next time A makes the same request to B? One problem is that I'm not sure what processes would actually be "keeping" the ends of the "kept alive" connections. At each end, would it be the parent httpd process, or the individual httpd child process that made/answered the request? I'm thinking that if A had to fork a CGI that in turn talked to B, the kept-alive connection would be lost as soon as the CGI process on A died (socket timeouts notwithstanding). But what if the request from A to B is made from within a mod_perl module, or within an Apache::Registry script? Along the same line of thought (assuming this has made any sense so far), what happens when you throw ProxyPass/ProxyPassReverse into the mix? What (if anything) can be done to take advantage of KeepAlive then? === Subject: Re: Does mod_perl have anything to do with KeepAlive? From: Stas Bekman <stas@stason.org> Date: Tue, 28 Nov 2000 14:08:11 +0100 (CET) On Tue, 28 Nov 2000, Larry Leszczynski wrote: > Hi All - > > > I'm hoping for some enlightenment about how KeepAlive is implemented in > > Apache and whether KeepAlive even comes into play when front-end and > > back-end mod_perl servers communicate with each other via HTTP. > > I suppose I shouldn't have started off my previous post with such a > general-sounding comment. Thanks for all the pointers to the KeepAlive > section in the mod_perl guide, which I have read before and which doesn't > answer the questions I was asking below. > > I'll try rephrasing, I'm still hoping for info regarding the questions > that follow: > > mod_backhand takes advantage of KeepAlive to speed up communications > between a front-end server and a set a back-end servers that feed data to > the front-end. I'm trying to figure out how that works and if I can take > advantage of KeepAlive the same way using mod_perl front-end and back-end > servers but without running mod_backhand. > > Suppose front-end server A is handling user requests. In the process of > handling a front-end request, suppose I use LWP or equivalent to make a > HTTP request from A to a back-end server B to get some data that is > needed. Assuming all the right headers are set for KeepAlive to work > (content length, etc.), can the connection between A and B even take > advantage of KeepAlive for the next time A makes the same request to B? > > One problem is that I'm not sure what processes would actually be > "keeping" the ends of the "kept alive" connections. At each end, would it > be the parent httpd process, or the individual httpd child process that > made/answered the request? > > I'm thinking that if A had to fork a CGI that in turn talked to B, the > kept-alive connection would be lost as soon as the CGI process on A died > (socket timeouts notwithstanding). But what if the request from A to B is > made from within a mod_perl module, or within an Apache::Registry script? > > Along the same line of thought (assuming this has made any sense so far), > what happens when you throw ProxyPass/ProxyPassReverse into the mix? What > (if anything) can be done to take advantage of KeepAlive then? Before trying to answer your question, let me ask you another question. What's the average run time of you mod_perl scripts? Is it 2 to 5 msecs? Or is it 0.5 to 1 sec? If you are in the former range this question makes sense, well may be. If you are in the latter range, you are wasting your time. KeepAlive comes to overcome the overhead of initiating connections between the browser and the server. It's useful when you serve static pages, because they are delivered in matter of a few milli-seconds. Which is somewhat comparable with the overhead of creating the connection... or very fast mod_perl code whose run time comparable to delivery of static pages (we have simple ads serving at 4-6msec). KeepAlive helps a lot with SSL connections (https) where the handshake is a few (4-5?) times slower compared to http, but it's still significant in the same range of run times. If your average run time is 10-100 slower than 5 msec, this overhead is insignificant since it comes down to something like 0.01% of the total response time over http and probably 0.05% over https. Now do you still want the KeepAlive? === Subject: Re: Does mod_perl have anything to do with KeepAlive? From: Matt Sergeant <matt@sergeant.org> Date: Tue, 28 Nov 2000 14:46:42 +0000 (GMT) On Tue, 28 Nov 2000, Larry Leszczynski wrote: > Suppose front-end server A is handling user requests. In the process of > handling a front-end request, suppose I use LWP or equivalent to make a > HTTP request from A to a back-end server B to get some data that is > needed. Assuming all the right headers are set for KeepAlive to work > (content length, etc.), can the connection between A and B even take > advantage of KeepAlive for the next time A makes the same request to B? If you use HTTP::GHTTP, and keep the same request object around in server memory, you can set the appropriate keepalive headers, and it should re-use the same connection next time around assuming the keepalive hasn't timed out. === Subject: Re: Does mod_perl have anything to do with KeepAlive? From: Stas Bekman <stas@stason.org> Date: Tue, 28 Nov 2000 21:28:37 +0100 (CET) On 28 Nov 2000, Joe Schaefer wrote: > Stas Bekman <stas@stason.org> writes: > > > Before trying to answer your question, let me ask you another > > question. What's the average run time of you mod_perl scripts? Is it 2 to > > 5 msecs? Or is it 0.5 to 1 sec? If you are in the former range this > > question makes sense, well may be. If you are in the latter range, you are > > wasting your time. > > I disagree, naturally ;). With respect to the effectiveness of keepalives, > there are many factors that come into play - not least of which are your > own site design and consideration of the effects of TCP slow start. Long > story short, IMHO there is no way to distill a universal answer for whether > one should or should not enable http keepalives. > > For the servers I manage, the effect of enabling keepalives on the browser- > proxy connection is quite significant. Over DSL connection to a live site > situated thousands of miles away (20+hops), here's my apachebench stats: > > > % ./ab -n 500 -c 10 http://front.end/proxied/to/backend/content_handler > > (The mod_perl content handler here grabs content from a mysql server > via DBI - it is decidedly non-trivial :) > > ... > > Document Length: 1807 bytes > > Concurrency Level: 10 > Time taken for tests: 21.539 seconds > Complete requests: 500 > Failed requests: 0 > Total transferred: 995500 bytes > HTML transferred: 903500 bytes > Requests per second: 23.21 > Transfer rate: 46.22 kb/s received > > Connnection Times (ms) > min avg max > Connect: 60 129 3064 > Processing: 107 298 250 > Total: 167 427 3314 > > Same URL with keep-alives enabled: > > % ./ab -k -n 500 -c 10 http://front.end/proxied/to/backend/content_handler > > ... > > Document Length: 1807 bytes > > Concurrency Level: 10 > Time taken for tests: 15.047 seconds > Complete requests: 500 > Failed requests: 0 > Keep-Alive requests: 500 > Total transferred: 1014010 bytes > HTML transferred: 903500 bytes > Requests per second: 33.23 > Transfer rate: 67.39 kb/s received > > Connnection Times (ms) > min avg max > Connect: 0 1 93 > Processing: 99 295 2507 > Total: 99 296 2600 > This is not a real world benchmark. It may generate the real world load, but not the real world usage. And once you realize that this cool speedup that you show doesn't really happen. User requests a single page at a time. The connection is tied to the browser. User will not issue a new request in the same rate as ab does. I'd say it takes at least 5-10 secs for user to read the page and you don't want to keep the mod_perl server tied all this time doing nothing. Even the front-end server, since you will end up with thousands of front-end servers if you will use a big KeepAlive. > Any way you slice it, that is a _huge_ difference! You just have > to test the effects yourself to see if it keepalives are worth > running on your server. That's true, my point was the same -- check your numbers and see whether it helps or not. Definitely not with ab or any other benchmark tool. === Subject: Re: Does mod_perl have anything to do with KeepAlive? From: Joe Schaefer <joe@sunstarsys.com> Date: 28 Nov 2000 15:51:47 -0500 Stas Bekman <stas@stason.org> writes: > This is not a real world benchmark. It may generate the real world > load, but not the real world usage. And once you realize that this > cool speedup that you show doesn't really happen. > Of course not- I only posted those results to show that under certain real conditions, it can make a real difference. Often times a single url will contain links to 20+ url's on the same server (many of them 304's). If you have keepalives enabled (even if only for 1 or 2 sec's), the page loading wait is often noticable for modem users. In my particular line of work, any excess latency is intolerable. My customers want almost instantaneous page loads, so my servers are built to accomodate them. Heavy server loads are not of paramount concern. I'm sure that is quite different from what your needs are, and that's my point. It all depends. > > That's true, my point was the same -- check your numbers and see > whether it helps or not. Definitely not with ab or any other benchmark > tool. > Nothing wrong with ab - just know it's limitations (or how to make it say what you want ;). === Subject: Re: Does mod_perl have anything to do with KeepAlive? From: Stas Bekman <stas@stason.org> Date: Tue, 28 Nov 2000 22:02:37 +0100 (CET) On 28 Nov 2000, Joe Schaefer wrote: > Stas Bekman <stas@stason.org> writes: > > > This is not a real world benchmark. It may generate the real world > > load, but not the real world usage. And once you realize that this > > cool speedup that you show doesn't really happen. > > > > Of course not- I only posted those results to show that under certain > real conditions, it can make a real difference. Often times a single > url will contain links to 20+ url's on the same server (many of them > 304's). If you have keepalives enabled (even if only for 1 or 2 sec's), > the page loading wait is often noticable for modem users. > > In my particular line of work, any excess latency is intolerable. > My customers want almost instantaneous page loads, so my servers > are built to accomodate them. Heavy server loads are not of > paramount concern. > > I'm sure that is quite different from what your needs are, and > that's my point. It all depends. > > > That's true, my point was the same -- check your numbers and see > > whether it helps or not. Definitely not with ab or any other benchmark > > tool. > > > > Nothing wrong with ab - just know it's limitations (or how to make it > say what you want ;). Joe, I agree with you absolutely. Each one has to evaluate his own situation and configure things based on the requirement. I just wanted to make sure that folks won't jump on the wrong conclusion based on your specific case benchmark to run and enable the KeepAlive on their machine, which in the average case will sky rocket the memory usage as the number of tied processes will go up. ===