Re: Does mod_perl have anything to do with KeepAlive?
Larry Leszczynski [EMAIL PROTECTED] 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 -- Dave Hodgkinson, http://www.hodgkinson.org Editor-in-chief, The Highway Star http://www.deep-purple.com Apache, mod_perl, MySQL, Sybase hired gun for, well, hire - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does mod_perl have anything to do with KeepAlive?
On Mon, 27 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. http://perl.apache.org/guide/performance.html#KeepAlive 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? Larry Leszczynski [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does mod_perl have anything to do with KeepAlive?
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? Thanks, Larry Leszczynski [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does mod_perl have anything to do with KeepAlive?
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? _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does mod_perl have anything to do with KeepAlive?
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. -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does mod_perl have anything to do with KeepAlive?
On 28 Nov 2000, Joe Schaefer wrote: Stas Bekman [EMAIL PROTECTED] 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 193 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. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does mod_perl have anything to do with KeepAlive?
Stas Bekman [EMAIL PROTECTED] 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 Schaefer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does mod_perl have anything to do with KeepAlive?
On 28 Nov 2000, Joe Schaefer wrote: Stas Bekman [EMAIL PROTECTED] 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. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Does mod_perl have anything to do with KeepAlive?
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. 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? Larry Leszczynski [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
