You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by cr...@animalhead.com on 2009/08/26 12:43:58 UTC
RFC: Apache2::CloseKeepAlive
I'm working toward contributing a module with this working title
to CPAN, and would like your comments and advice.
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
I'm tentatively convinced it's worth contributing, but you're welcome
to tell me why it's not. For sure, your advice on how to improve it
will be very welcome.
Specifically:
• What CPAN module(s) is (are) most like this one, to use as
model(s) for how to package, test, and install it?
• The plan is to use Module::Build and Apache::Test.
What else or something different?
• Is something as specialized as this worth including in the
GP Perl libraries? Or is it better to just ask where the
mod_perl2 library is?
• Is inclusion in the GP Perl libraries a prerequisite or
assumption of Module::Build or of CPAN?
In addition to where to put the module itself, it needs a place to
put a companion DB-building app and a place for the resulting DB.
These are not standard features of a module installation.
Probably I just ask the user where they should go?
If so, how do I use the answers?
Thanks for being there,
cmac
Re: RFC: Apache2::CloseKeepAlive
Posted by Perrin Harkins <ph...@gmail.com>.
Seriously, this is not something you need to be concerned about.
There are dozens of places for people to get information about how to
install CPAN modules. Most people use the CPAN shell and set it up to
put things where they want them.
- Perrin
On Wed, Aug 26, 2009 at 1:31 PM, <cr...@animalhead.com> wrote:
> Including a note about how to do something in an installation dialog,
> for people who wouldn't otherwise know, is not controlling anything.
> If that's against CPAN principles, the principles need some work!
>
> cmac
>
> On Aug 26, 2009, at 9:30 AM, Perrin Harkins wrote:
>
>> On Wed, Aug 26, 2009 at 12:21 PM, <cr...@animalhead.com> wrote:
>>>
>>> How does one specify that? It sounds like esoteric knowledge that
>>> only a few users will know, and I'd like to empower people not to
>>> clog up their GP Perl library with a module that can be used in
>>> exactly one place.
>>
>> It's in the docs for Module::Build. Seriously, you have no control
>> over where users install your module. Attempting to control it is
>> against the principles of CPAN distributions.
>>
>> - Perrin
>
>
Re: RFC: Apache2::CloseKeepAlive
Posted by Michael Peters <mp...@plusthree.com>.
Perrin Harkins wrote:
>> It's not a run time option. The subject is a mod_perl2 script, that
>> can only be used within the Apache2 server. I can't conceive why the
>> DB name would ever change, and multiple programs won't use the module.
>
> Some people have many apache installations on one machine, or may
> install new ones after installing your module.
This is the main point I guess I didn't clearly express. Don't assume that just
because you have only 1 apache installed that everyone else does too.
Also, if you deviate from what the standard install tools do (which is install
things based on how CPAN is configured on that machine) then actually make it
harder for people who need to install your module in a non-standard place. This
is pretty common for dev environments. I (and most Perl people I would assume)
already know how to tell EU::MM or Module::Build how to put things where I want
them. If you do it differently it makes our lives harder.
I guess what it comes down to is that putting modules into non-standard places
is pretty common, so please don't implement your own way of doing that.
--
Michael Peters
Plus Three, LP
Re: RFC: Apache2::CloseKeepAlive
Posted by Perrin Harkins <ph...@gmail.com>.
On Wed, Aug 26, 2009 at 9:23 PM, <cr...@animalhead.com> wrote:
> I have no idea what EU::MM is. Candy from Europe?
Good guess, but it's actually ExtUtils::MakeMaker. It's the CPAN
install mechanism that Module::Build was written to replace.
> My plan was to run the script the first time under Build.PL, to
> verify that it succeeds and because without the DB there can be no
> testing.
I'd suggest trying to find another way. Installers that ask questions
are a real problem for automated scripts and distribution packagers
and are definitely discouraged. Take a look at the module authors
list for more discussion on this. There are some standard ways of
allowing people to skip prompts.
One thing you could do for testing is to ship a small set of test
files and a pre-built db for them.
> It's not a run time option. The subject is a mod_perl2 script, that
> can only be used within the Apache2 server. I can't conceive why the
> DB name would ever change, and multiple programs won't use the module.
Some people have many apache installations on one machine, or may
install new ones after installing your module.
> I personally regard "docs already out there" as things that should
> be restated "in here" whenever the user can profit from them.
There's no harm in giving them a pointer to the relevant part of the
Module::Build docs or an example of using the correct flags. Go
ahead.
> It seems that you and Perrin are in the same boat, which has "One Perl
> Library For All" painted on it. I am in a different boat with the
> authors of various mod_perl books. I set up my site under the guidance
> of "Practical mod_perl" p. 34:
Sorry, I think you're mis-reading the advice in these books. What the
authors are talking about there is your own local code, not CPAN
modules. CPAN modules have a standard location and a standard
mechanism for changing it for special cases. On the other hand, you
would never put your own local code in the site_perl directory, so
that goes in your mod_perl lib directory and gets added to @INC. I
hope that explains why we're surprised to hear this idea of putting
mod_perl modules in a separate place -- it's one I've never heard
before.
- Perrin
Re: RFC: Apache2::CloseKeepAlive
Posted by cr...@animalhead.com.
On Aug 26, 2009, at 11:44 AM, Michael Peters wrote:
> craig@animalhead.com wrote:
>> The installation process needs to know at least:
>> 1. where the accompanying DB-building script should go
>
> Module::Build knows where to put bin/ or script/ files and it does
> so according to how Perl and CPAN are configured. I assume EU::MM
> does too.
>
So if I put the script in a subdirectory bin of Apache2-
CloseKeepAlive-n.nn/,
the install step should automatically put it somewhere in the path.
This is good information, thank you!
I have no idea what EU::MM is. Candy from Europe?
>> 2. where the DB that the app builds should go
>
> That's probably something your application should allow to be
> specified, either a command line option to the script or an option
> to the module, or both.
>
My plan was to run the script the first time under Build.PL, to
verify that it succeeds and because without the DB there can be no
testing. In which case, asking the user where to put the DB, and
propagating the answer to the script source and the module source,
seems to me like the easiest course for everyone. This kind of
prompt is not evil, in that the automated testers can be handled
by giving the query a default, maybe '/tmp'.
>> How can such necessary things be determined, other than by asking
>> the user?
>
> If it's a run time option (and can be changed or multiple programs
> can use this and thus want different values) don't ask for it at
> install time.
>
It's not a run time option. The subject is a mod_perl2 script, that
can only be used within the Apache2 server. I can't conceive why the
DB name would ever change, and multiple programs won't use the module.
>> I was just going to add a note before or after these two queries,
>> that if they have a mod_perl2 library and want the module to go
>> there, they should "do this".
>
> Putting extra docs in your module is ok, but I personally wouldn't
> repeat the docs that are already out there.
>
I personally regard "docs already out there" as things that should
be restated "in here" whenever the user can profit from them.
>> As I just wrote to Perrin off-list, since only a tiny fraction of
>> CPAN downloads are mod_perl2 modules, no one can configure CPAN
>> for a mod_perl2 library.
>
> All perl libraries should go in the same place IMO. Whether it's
> Apache specific, or GTK or something else. I don't want to have to
> mess with @INC just because someone put something someplace non-
> standard.
It seems that you and Perrin are in the same boat, which has "One Perl
Library For All" painted on it. I am in a different boat with the
authors of various mod_perl books. I set up my site under the guidance
of "Practical mod_perl" p. 34:
"Now you have to select a directory where all the mod_perl scripts
and
modules will be placed. We usually create a directory called modperl
under our home directory for this purpose (e.g., /home/stas/modperl),
but it is also common to create a directory called perl under your
Apache server root, such as /usr/local/apache/perl."
(It's /usr/local/apache2/plib on my site.)
This theme is echoed on p. 58 of the "mod_perl2 User's Guide":
"You often need to adjust the contents of @INC before the server
starts,
usually to give the server additional places to look for your
mod_perl code.
There are several ways to do this:
• startup.pl
In the startup file you can use the lib pragma like so:
use lib qw(/home/httpd/projectl/lib/tmp/lib);
use lib qw(/home/httpd/project2/lib);
• httpd.conf
In httpd.conf you can use the PerlSwitches directive to pass
arguments
to Perl as you do from the command line.
PerlSwitches -I/home/httpd/projectl/lib -I/tmp/lib
PerlSwitches -I/home/httpd/project2/lib"
And on p. 61 of the "mod_perl Developer's Cookbook":
"For a similar option, configure your startup.pl as
use lib qw(/home/www/lib);
...
By default, mod_perl adds two directories to @INC: ServerRoot/ and
ServerRoot/lib/perl/, where ServerRoot is the value of the ServerRoot
directive.
...
If you are using a startup.pl to preload your modules, you will
probably need to take advantage of the use lib syntax."
Given all this, I blithely talk about "the mod_perl library" as if
it's a standard part of every mod_perl site, and you and Perrin
regard me as someone from another planet.
Which is actually true, but that's another story.
>
>> So now if Makefile.PL doesn't find 'mm' in /usr/local/lib, it
>> prompts the user to enter the path to 'mm', which is then passed
>> to Devel::CheckLib. The query is accompanied by a note showing
>> the URL from which 'mm' can be downloaded.
>
> Personally, I'd just bomb out if you can't find the lib (and
> Devel::CheckLib is good for that). Give the user a message that you
> can't find the library and then exit. I doubt that someone who has
> a library that's not in the system libs will know where it is, and
> if they do they can just as easily set LD_LIBRARY_PATH themselves.
>
This happens to me fairly regularly when installing things, that the
install script asks me a question I can't answer. Which I handle
by starting up another shell that I use to find the answer, then go
back to the first shell and enter it.
>> On the other hand, my latest version 0.58 has only been tested by
>> one tester, a week after uploading it. Maybe that's because of
>> the new query in Makefile.PL!
>
> That's why prompts are evil. Automated tests won't work. So just
> bomb out and at least you'll get lots of UNKNOWN test results which
> is better than nothing :)
Your attitudes and mine are so different! First, I would never just
"give the user a message that you can't find the library and then exit".
It would have to include the URL where they can get the library.
Second, I regard each UNKNOWN result as a personal failing, in that
I didn't give the tester the information he/she needed to produce a
more useful result. So UNKNOWN is worse than nothing.
More than enough said, at least for now,
cmac
Re: RFC: Apache2::CloseKeepAlive
Posted by Michael Peters <mp...@plusthree.com>.
craig@animalhead.com wrote:
> The installation process needs to know at least:
> 1. where the accompanying DB-building script should go
Module::Build knows where to put bin/ or script/ files and it does so according
to how Perl and CPAN are configured. I assume EU::MM does too.
> 2. where the DB that the app builds should go
That's probably something your application should allow to be specified, either
a command line option to the script or an option to the module, or both.
> How can such necessary things be determined, other than by asking
> the user?
If it's a run time option (and can be changed or multiple programs can use this
and thus want different values) don't ask for it at install time.
> I was just going to add a note before or after these two queries,
> that if they have a mod_perl2 library and want the module to go
> there, they should "do this".
Putting extra docs in your module is ok, but I personally wouldn't repeat the
docs that are already out there.
> As I just wrote to Perrin off-list, since only a tiny fraction of
> CPAN downloads are mod_perl2 modules, no one can configure CPAN
> for a mod_perl2 library.
All perl libraries should go in the same place IMO. Whether it's Apache
specific, or GTK or something else. I don't want to have to mess with @INC just
because someone put something someplace non-standard.
> So now if Makefile.PL doesn't find 'mm' in /usr/local/lib, it
> prompts the user to enter the path to 'mm', which is then passed
> to Devel::CheckLib. The query is accompanied by a note showing
> the URL from which 'mm' can be downloaded.
Personally, I'd just bomb out if you can't find the lib (and Devel::CheckLib is
good for that). Give the user a message that you can't find the library and then
exit. I doubt that someone who has a library that's not in the system libs will
know where it is, and if they do they can just as easily set LD_LIBRARY_PATH
themselves.
> On the other hand, my latest version 0.58 has only been tested by
> one tester, a week after uploading it. Maybe that's because of
> the new query in Makefile.PL!
That's why prompts are evil. Automated tests won't work. So just bomb out and at
least you'll get lots of UNKNOWN test results which is better than nothing :)
--
Michael Peters
Plus Three, LP
Re: RFC: Apache2::CloseKeepAlive
Posted by cr...@animalhead.com.
The installation process needs to know at least:
1. where the accompanying DB-building script should go
2. where the DB that the app builds should go
How can such necessary things be determined, other than by asking
the user?
I was just going to add a note before or after these two queries,
that if they have a mod_perl2 library and want the module to go
there, they should "do this".
As I just wrote to Perrin off-list, since only a tiny fraction of
CPAN downloads are mod_perl2 modules, no one can configure CPAN
for a mod_perl2 library.
Perhaps my attitude toward installation dialogs has been warped
by recent experience with my previous CPAN module IPC::MMA. The
install for version 0.54 contained no prompts. Its results came
out 75% unknown, because few test environments included a
necessary C library 'mm'. One of the chief testers suggested I
should add Devel::CheckLib to Makefile.PL.
So now if Makefile.PL doesn't find 'mm' in /usr/local/lib, it
prompts the user to enter the path to 'mm', which is then passed
to Devel::CheckLib. The query is accompanied by a note showing
the URL from which 'mm' can be downloaded.
On the other hand, my latest version 0.58 has only been tested by
one tester, a week after uploading it. Maybe that's because of
the new query in Makefile.PL!
Best Regards,
cmac
On Aug 26, 2009, at 10:44 AM, Michael Peters wrote:
> craig@animalhead.com wrote:
>> Including a note about how to do something in an installation dialog,
>> for people who wouldn't otherwise know, is not controlling anything.
>
> Please don't put a dialog in your installation process! CPAN is
> supposed to be automatic after it's been configured. There are some
> rare occasions where it makes sense to ask some questions, but
> where you want the module installed is not one of them. CPAN takes
> care of that.
>
> --
> Michael Peters
> Plus Three, LP
Re: RFC: Apache2::CloseKeepAlive
Posted by Michael Peters <mp...@plusthree.com>.
craig@animalhead.com wrote:
> Including a note about how to do something in an installation dialog,
> for people who wouldn't otherwise know, is not controlling anything.
Please don't put a dialog in your installation process! CPAN is supposed to be
automatic after it's been configured. There are some rare occasions where it
makes sense to ask some questions, but where you want the module installed is
not one of them. CPAN takes care of that.
--
Michael Peters
Plus Three, LP
Re: RFC: Apache2::CloseKeepAlive
Posted by cr...@animalhead.com.
Including a note about how to do something in an installation dialog,
for people who wouldn't otherwise know, is not controlling anything.
If that's against CPAN principles, the principles need some work!
cmac
On Aug 26, 2009, at 9:30 AM, Perrin Harkins wrote:
> On Wed, Aug 26, 2009 at 12:21 PM, <cr...@animalhead.com> wrote:
>> How does one specify that? It sounds like esoteric knowledge that
>> only a few users will know, and I'd like to empower people not to
>> clog up their GP Perl library with a module that can be used in
>> exactly one place.
>
> It's in the docs for Module::Build. Seriously, you have no control
> over where users install your module. Attempting to control it is
> against the principles of CPAN distributions.
>
> - Perrin
Re: RFC: Apache2::CloseKeepAlive
Posted by Perrin Harkins <ph...@gmail.com>.
On Wed, Aug 26, 2009 at 12:21 PM, <cr...@animalhead.com> wrote:
> How does one specify that? It sounds like esoteric knowledge that
> only a few users will know, and I'd like to empower people not to
> clog up their GP Perl library with a module that can be used in
> exactly one place.
It's in the docs for Module::Build. Seriously, you have no control
over where users install your module. Attempting to control it is
against the principles of CPAN distributions.
- Perrin
Re: RFC: Apache2::CloseKeepAlive
Posted by cr...@animalhead.com.
On Aug 26, 2009, at 9:05 AM, Perrin Harkins wrote:
> On Wed, Aug 26, 2009 at 11:41 AM, <cr...@animalhead.com> wrote:
>> The general purpose Perl library is headed at /usr/local/lib/perl5
>> on my system. What I was asking is whether there's any reason
>> to put Apache2::CloseKeepAlive in it, being as it's so specialized,
>> or just copy it to a mod_perl2-specific library (/usr/local/
>> apache2/plib
>> on my system). Maybe the latter if the user says such a thing
>> exists,
>> else the former?
>
> You don't get to choose that. You just do a standard Module::Build
> distribution, and if people want to install your module somewhere
> outside of the site_lib, they specify that at install time.
>
> - Perrin
How does one specify that? It sounds like esoteric knowledge that
only a few users will know, and I'd like to empower people not to
clog up their GP Perl library with a module that can be used in
exactly one place.
Re: RFC: Apache2::CloseKeepAlive
Posted by Perrin Harkins <ph...@gmail.com>.
On Wed, Aug 26, 2009 at 11:41 AM, <cr...@animalhead.com> wrote:
> The general purpose Perl library is headed at /usr/local/lib/perl5
> on my system. What I was asking is whether there's any reason
> to put Apache2::CloseKeepAlive in it, being as it's so specialized,
> or just copy it to a mod_perl2-specific library (/usr/local/apache2/plib
> on my system). Maybe the latter if the user says such a thing exists,
> else the former?
You don't get to choose that. You just do a standard Module::Build
distribution, and if people want to install your module somewhere
outside of the site_lib, they specify that at install time.
- Perrin
Re: RFC: Apache2::CloseKeepAlive
Posted by cr...@animalhead.com.
On Aug 26, 2009, at 7:03 AM, Perrin Harkins wrote:
> What's GP Perl?
The general purpose Perl library is headed at /usr/local/lib/perl5
on my system. What I was asking is whether there's any reason
to put Apache2::CloseKeepAlive in it, being as it's so specialized,
or just copy it to a mod_perl2-specific library (/usr/local/apache2/plib
on my system). Maybe the latter if the user says such a thing exists,
else the former?
cmac
Re: RFC: Apache2::CloseKeepAlive
Posted by Perrin Harkins <ph...@gmail.com>.
On Wed, Aug 26, 2009 at 6:43 AM, <cr...@animalhead.com> wrote:
> I'm tentatively convinced it's worth contributing, but you're welcome
> to tell me why it's not.
I think that setting a very short Keep-Alive timeout would be almost
as good. More importantly, you shouldn't serve any static files from
mod_perl. You should serve those from a proxy instead.
However, I don't see any problem with releasing your code. It's an
interesting idea and shows a novel use of IPC::MMA.
> • The plan is to use Module::Build and Apache::Test.
> What else or something different?
Those are fine.
> • Is something as specialized as this worth including in the
> GP Perl libraries? Or is it better to just ask where the
> mod_perl2 library is?
What's GP Perl?
> In addition to where to put the module itself, it needs a place to
> put a companion DB-building app and a place for the resulting DB.
> These are not standard features of a module installation.
> Probably I just ask the user where they should go?
> If so, how do I use the answers?
You can ask on the module authors list, but I think you'll find some
examples of modules with executable scripts if you poke around CPAN a
little. LWP comes with some.
- Perrin
Re: RFC: Apache2::CloseKeepAlive
Posted by ma...@animalhead.com.
On Aug 26, 2009, at 7:39 AM, Adam Prime wrote:
> A non-code comment, but there seems to be some consternation about
> the "same terms as perl itself" license. See the link below:
>
> http://perlbuzz.com/2009/07/help-end-licensing-under-same-terms-as-
> perl-itself.html
Inside many programmers, nascent lawyers lurk?
The linked-to CPAN Licensing Guidelines
http://www.perlfoundation.org/cpan_licensing_guidelines
was easier to read and didn't cut off the right sides of code segments.
I modified the end of
http://www.animalhead.com/CloseKeepAlive.html
accordingly.
Thanks,
cmac
Re: RFC: Apache2::CloseKeepAlive
Posted by Adam Prime <ad...@utoronto.ca>.
craig@animalhead.com wrote:
> I'm working toward contributing a module with this working title
> to CPAN, and would like your comments and advice.
A non-code comment, but there seems to be some consternation about the
"same terms as perl itself" license. See the link below:
http://perlbuzz.com/2009/07/help-end-licensing-under-same-terms-as-perl-itself.html
Adam
Re: RFC: Apache2::CloseKeepAlive
Posted by ma...@animalhead.com.
Thanks for your comments. They lead to lots to think about and try.
>
> 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?
>
> Ask Google ;)
>
> http://www.websiteoptimization.com/speed/tweak/css-sprites/
>
You should have said "CSS sprites" rather than "sprite sheets".
The techniques cited look much harder to use than CloseKeepAlive, plus
the comments at the end of the article say they don't work on MSIE, or
(per another comment) on MSIE < 8.
Looks like a technique that needs a new CPAN module to help mere mortals
use it. Something to keep you out of mischief?
Anyway I guess I'll muddle through with submitting CloseKeepAlive to
CPAN.
(This list has been quite helpful as to how to do that.) Obviously
it's not for
you, but maybe it can be useful to people less technologically advanced
than you. Or as an example of how to use IPC::MMA.
Thanks again,
cmac
Re: RFC: Apache2::CloseKeepAlive
Posted by Bill Moseley <mo...@hank.org>.
On Thu, Aug 27, 2009 at 5:20 PM, <cr...@animalhead.com> wrote:
>
> Yes that's the point, but I would substitute 'apache processes' for
> 'mod_perl processes'.
>
This is a mod_perl module, right?
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.
>
Got YSlow installed? Run it on your site.
Have you reviewed this? http://developer.yahoo.com/performance/rules.html
That's where I'd start.
Others:
http://www.websiteoptimization.com/services/analyze/
http://code.google.com/speed/page-speed/
http://stevesouders.com/hpws/rules.php
> Anything that keeps a connection open forever is going to end up with a lot
> of connections?
>
They are pooled.
http://www.danga.com/perlbal/
> 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?
>
Ask Google ;)
http://www.websiteoptimization.com/speed/tweak/css-sprites/
--
Bill Moseley
moseley@hank.org
Re: RFC: Apache2::CloseKeepAlive
Posted by Bill Moseley <mo...@hank.org>.
On Thu, Aug 27, 2009 at 5:20 PM, <cr...@animalhead.com> wrote:
> 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.
>
By the way,
You might also want to look at something like S3 to server your static
content. If you are low traffic (with potential spikes) then it will be
much cheaper than a "real" CDN.
Here's one tutorial:
http://net.tutsplus.com/misc/use-amazon-s3-firefox-to-serve-static-files/
--
Bill Moseley
moseley@hank.org
Re: RFC: Apache2::CloseKeepAlive
Posted by Michael Ludwig <ml...@as-guides.com>.
Adam Prime schrieb:
> Michael Ludwig wrote:
>> Sprites are useful for collections of related of the same size
>> and purpose.
>
> You don't have to restrict them to images of the same size. You
> can use a sprited image to replace any fixed size image, and any
> background image that repeats in one direction or the other (but
> not both).
I thought that having the images tiled up regularly would make the
CSS offsets easy to calculate. You'd only need the sequence number
of the image and the sprite layout (say, 10 x 10) to calculate the
offsets.
But you appear to have had more exposure to sprites than me, so
you're probably right.
--
Michael Ludwig
Re: RFC: Apache2::CloseKeepAlive
Posted by Adam Prime <ad...@utoronto.ca>.
Michael Ludwig wrote:
> Sprites are useful for collections of related of the same size and
> purpose.
You don't have to restrict them to images of the same size. You can use
a sprited image to replace any fixed size image, and any background
image that repeats in one direction or the other (but not both). One
caveat about that though is that background images don't print in most
(maybe all) current browsers.
In experiments with sprites and changes to some JS, we've managed to
reduce render times on our websites by nearly half, and reduced the
number of elements retrieved from the page to about a quarter of what
they used to be in some cases.
Adam
Re: RFC: Apache2::CloseKeepAlive
Posted by cr...@animalhead.com.
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.
Re: RFC: Apache2::CloseKeepAlive
Posted by Bill Moseley <mo...@hank.org>.
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?
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? For
example, javascript probably should be loaded last in the HTML file. Then
the bulk of images are often loaded via css. Are you scanning the css,
too? What if you have multiple servers? Connections will be on different
machines.
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). Use sprite
sheets to reduce the number of required connections. 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.
--
Bill Moseley
moseley@hank.org