On Aug 27, 2009, at 10:43 AM, Bill Moseley wrote:
On Wed, Aug 26, 2009 at 3:43 AM, <cr...@animalhead.com> 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
http://www.animalhead.com/CloseKeepAlive.html
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.
