perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: RFC: Apache2::CloseKeepAlive
Date Fri, 28 Aug 2009 00:20:33 GMT
On Aug 27, 2009, at 10:43 AM, Bill Moseley wrote:
> On Wed, Aug 26, 2009 at 3:43 AM, <> wrote:
> The short story is that it's a mod_perl2 mechanism for optimizing
> the KeepAlive option in the Apache2 server. The long story is at
> Interesting.  But, is there really a probem to solve here?
> Is the point here to free up mod_perl processes faster so that they  
> can handle other connections?  Does that really have anything to do  
> with better performace in serving up pages?
Yes that's the point, but I would substitute 'apache processes' for  
'mod_perl processes'.

My site's front page preloads sixty-some jpg thumbnails.  Years ago  
it was evident that KeepAlive On was needed to allow this to complete  
in a reasonable length of time. e.g., on a 1.5M ADSL line it takes  
2-3 seconds with KA on, 6-8 seconds with KA off.  So it seems that  
connection establishment and process dispatch take a while.

Even though the Javascript that does the preloading on my front page  
only requests 3 images ahead of download completion, the response  
shown to a quick user clicking on a link is noticeably degraded by  
the preload stream.  So you want to get the preloading over with  
before most users will click on a link.

I decided to write this module about a year ago, when I read an  
article that the latest Firefoxes would open up to 6 connections to  
download supporting files, and that the MSIE team was considering  
leapfrogging them to 8.  With my cheapskate ISP plan limiting the  
total number of processes, hanging 6 or 8 of them at a time (with a  
plain KeepAlive On) was a pretty scary idea.

> I don't think you can look at file extensions and determine when to  
> close the connection.  Can you count on how the browser will send  
> requests?

Maybe not strictly, but in general browsers request files in the  
order they are requested in the .html file.  In the case of a lot  
of .jpg's the browser may take their relative file sizes into account.

> For example, javascript probably should be loaded last in the HTML  
> file.

Javascript that is involved in building the pages wants to get called  
out as early in the header as possible, either before or after the  
css.  JavaScript that only interacts with the user could come last,  
but by doing that you take the chance of responding badly to a  
"quick" user.

> Then the bulk of images are often loaded via css.  Are you scanning  
> the css, too?

The scanning script that accompanies the module could easily do  
this.  I will count your email as a first request for that feature,  
and if I get 2 or 3 I'll add it.  If that happens, can I count on you  
for a sample of a .css that loads images?

> What if you have multiple servers?  Connections will be on  
> different machines.
Clearly that's a different environment than CloseKeepAlive is  
designed for.

> If customizing the keep alive is that critical then I think it's  
> time to look at other techniques.  Use a balancer and let it  
> decided how to manage the connections (perlbal keeps the connection  
> open forever).
Anything that keeps a connection open forever is going to end up with  
a lot of connections?

> Use sprite sheets to reduce the number of required connections.

I looked up "sprite sheets" and they seem to be graphics that include  
lots of little tiled figures used in video games.
How does a browser know to split them up into separate images that  
pages can then call out individually?

> Use a CDN and cache static content forever -- and rarely hit your  
> serve.  In the end, each "page view" should only be one request to  
> your mod_perl server anyway.
My site uses all defined headers to encourage proxies and browsers to  
cache files.  The performance of a site is the cross-product of all  
of the things that it does to improve performance.

But you can't just look at it from the server's point of view.  CKA  
is motivated by a desire to give the best possible performance/ 
responsiveness at the browser, that's consistent with keeping the  
load on the server reasonable.

View raw message