You are viewing a plain text version of this content. The canonical link for it is here.
Posted to asp@perl.apache.org by Josh Chamas <jo...@chamas.com> on 2003/05/06 08:19:07 UTC
[mp2] Making Apache::ASP optimized for mod_perl 2
Hey,
I just wanted to share my experience with making Apache::ASP
not use Apache::compat to run under mod_perl 2 ( 1.99_09 actually ).
Keeping Apache::ASP running under mod_perl 1 is important, so part
of the effort was to minimize code impact on ASP, while using the
correct APIs under mp2. I expect this work to be available for the
Apache::ASP 2.55 release, but this is still in development.
What I found was that the only APIs that I needed to trigger off of
a MP2 type constant was register_cleanup and send_http_header.
Following the example of Apache::compat, I basically did these things:
if($ModPerl2) {
$self->{r}->pool->cleanup_register(@_);
} else {
$self->{r}->register_cleanup(@_);
}
- and -
unless($Apache::ASP::ModPerl2) {
# don't need this for mod_perl2 it seems from Apache::compat
$r->send_http_header();
}
Besides not using Apache::compat, I tried also to not
&ModPerl::MethodLookup::preload_all_modules();
but ended up leaving it in because Apache::ASP uses so much of the
Apache API, via these necessary modules...
Apache::RequestRec
Apache::RequestUtil
Apache::RequestIO
Apache::Response
APR::Table
APR::Pool
Apache::Connection
Apache::Server
Apache::Log
that the savings in memory did not warrant explicitly listing just these
modules for loading. The savings was between 500K-2M post benchmark run
by explicitly loading, and I don't want to run the risk that I missed
some obscure Apache API code reference that comes up only rarely at runtime,
so I'll load in all the modules for now.
I also managed to get Apache::ASP working under modperl handler config
for an extra 5-10% performance speedup.
At the end of all this, I am finding that despite my best efforts, Apache::ASP
runs some 30-40% slower under Apache2/mp2 than Apache1/mp1. Though both perls
are perl 5.8, a big difference is that for mp2 the perl has usethreads defined,
but the perl 5.8 for mp1 does not. Maybe the thread layer has to do with the
slower performance? I believe that having the thread layer on for eventual
use of the Apache 2 worker mpm is essential, so this is why I compiled perl
that way for benchmarking.
Here are some benchmark numbers for comparison:
========== APACHE 1.x / mod_perl 1.x
Test Name Test File Hits/sec # of Hits Time(sec) secs/Hit Bytes/Hit Mem(KB)
--------- --------- --------- --------- --------- --------- --------- ---------
Apache::ASP v2.55 mod_perl 2000 h2000.asp 389.7 1952 5.01 0.002566 29025 29932
Apache::ASP v2.55 mod_perl Hello hello.asp 495.8 2480 5.00 0.002017 258 27384
Apache Server Header Tokens
---------------------------
Apache/1.3.27
OpenSSL/0.9.6g
PHP/4.3.0
mod_fastcgi/2.2.12
mod_perl/1.27
mod_ssl/2.8.12
========== APACHE 2.x / mod_perl 1.99 ( normal prefork mpm )
Test Name Test File Hits/sec # of Hits Time(sec) secs/Hit Bytes/Hit Mem(KB)
--------- --------- --------- --------- --------- --------- --------- ---------
Apache::ASP v2.55 mod_perl 2000 h2000.asp 258.2 1351 5.23 0.003873 29051 42572
Apache::ASP v2.55 mod_perl Hello hello.asp 334.6 1710 5.11 0.002988 284 36116
Apache Server Header Tokens
---------------------------
Apache/2.0.40
OpenSSL/0.9.6g
PHP/4.2.3
Perl/v5.8.0
Python/2.2.1
mod_perl/1.99_09
mod_python/3.0.1
mod_ssl/2.0.40
Regards,
Josh
________________________________________________________________
Josh Chamas, Founder phone:925-552-0128
Chamas Enterprises Inc. http://www.chamas.com
NodeWorks Link Checking http://www.nodeworks.com
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: [mp2] Making Apache::ASP optimized for mod_perl 2
Posted by Stas Bekman <st...@stason.org>.
Josh Chamas wrote:
> Stas Bekman wrote:
>
>>
>> May be in the spirit of ModPerl::MethodLookup, we call it
>> ModPerl::MethodLoad? Internally it'll use ModPerl::MethodLookup.
>>
>
> I don't have an intuition about the naming conventions yet...
> seems like this could go well as a Apache:: module or a ModPerl::Method
> one...
I put these into the ModPerl:: namespace, since this is really a mod_perl
thing, it's doesn't provide a glue for any Apache:: functionality.
> I like things have have a natural way of saying them like:
>
> use ModPerl::Methods qw(:mp1);
>
> it just sounds like how you would say it.
It's just a bit too abstract, even though it reads better as a prose. May be
this is less of an art:
use ModPerl::MethodLoad qw(:mp1);
but it's very explicit.
Also I thought of using this new potential module in Apache::compat, but now I
think that it's better to keep the list explicit.
>> Also I'm thinking about adding a special module called
>> ModPerl::ProductionTest, what it'll do is:
>>
>> $INC{'Apache/compat.pm'} = __FILE__;
>> $INC{'ModPerl/MethodLoad.pm'} = __FILE__;
>>
>
> I like this idea. It has to noop all other mass loading mechanisms,
> both module loading, and the subs that might be called from those modules,
> so that other modules can call those subs without erroring I guess
> at module compile time.
And it has to be loaded very early.
> It might go into the same namespace as
> ModPerl::Methods ( or whatever it ends up as ) too like
>
> use ModPerl::Methods qw(:mp1 :production);
But since it reverts the functionality of other modules as well, it's may be
better to have it in a different package? may be:
use ModPerl::ReleaseControl qw(:dev :prod);
and of course it should be possible to turn it on with setting an env var, so
one doesn't have to change the code when switching to the production env.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Making Apache::ASP optimized for mod_perl 2
Posted by Josh Chamas <jo...@chamas.com>.
Stas Bekman wrote:
>
> May be in the spirit of ModPerl::MethodLookup, we call it
> ModPerl::MethodLoad? Internally it'll use ModPerl::MethodLookup.
>
I don't have an intuition about the naming conventions yet...
seems like this could go well as a Apache:: module or a ModPerl::Method one...
I like things have have a natural way of saying them like:
use ModPerl::Methods qw(:mp1);
it just sounds like how you would say it.
> Also I'm thinking about adding a special module called
> ModPerl::ProductionTest, what it'll do is:
>
> $INC{'Apache/compat.pm'} = __FILE__;
> $INC{'ModPerl/MethodLoad.pm'} = __FILE__;
>
I like this idea. It has to noop all other mass loading mechanisms,
both module loading, and the subs that might be called from those modules,
so that other modules can call those subs without erroring I guess
at module compile time. It might go into the same namespace as
ModPerl::Methods ( or whatever it ends up as ) too like
use ModPerl::Methods qw(:mp1 :production);
Regards,
Josh
________________________________________________________________
Josh Chamas, Founder phone:925-552-0128
Chamas Enterprises Inc. http://www.chamas.com
NodeWorks Link Checking http://www.nodeworks.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Making Apache::ASP optimized for mod_perl 2
Posted by Stas Bekman <st...@stason.org>.
Josh Chamas wrote:
> Stas Bekman wrote:
>
>>
>>>> So an Apache::Common, might just be:
>>>>
>>>> package Apache::Common;
>>>
>>>
>>>
>>>
>>> I would suggest that Apache::Common be only the things we used to
>>> have in mp1 - for example, people are used to having $r->print and
>>> $r->server but $r->pool is new. even though we need pools for
>>> cleanups, I think _not_ hiding it will help people migrate as well.
>>
>>
>>
>> As I've explained in my reply to Josh, Apache::Common won't work, as
>> everybody has a different requirement from mp2. However if you want to
>> provide a list of modules to load to make it work as in mp1, I think
>> this is possible but the name should reflect that. For example
>> Apache::LoadMP1Modules or something like that.
>>
>
> How about some importer that was function based, say...
>
> use Apache::Loader qw(:common log_error :default you_name_it )
>
> :common might load the LoadMP1Modules for example, or this might
> just be :mp1 ... it might just be a ModPerl::Method helper ...
>
> use ModPerl::Method qw(:mp1)
>
> or something like that?
I like this.
again I don't think it's going to be easy to define what should be in
':common'. However it's quite easy to do:
use Apache::Loader qw(:request :server :mp1);
individual methods can be passed, and they will be automatically looked up
using ModPerl::MethodLookup. So we only need to hardcoded the module lists for
:request :server :mp1 and keep them in sync if new modules are added.
>> No matter what conveniece helpers we provide, I'd still strongly
>> suggest to CPAN authors not to use any of the helpers. Since in most
>> cases you don't need all the MP1 functionality for your specific CPAN
>> module, keep the list to a minimum.
>>
>
> Right. The keyword loader as above might be nice to have people specify
> groups they are interested in loading like the :mp1 group assuming they
> flexed most of that API.
May be in the spirit of ModPerl::MethodLookup, we call it ModPerl::MethodLoad?
Internally it'll use ModPerl::MethodLookup.
Also I'm thinking about adding a special module called
ModPerl::ProductionTest, what it'll do is:
$INC{'Apache/compat.pm'} = __FILE__;
$INC{'ModPerl/MethodLoad.pm'} = __FILE__;
so when anything tries to load Apache::compat or ModPerl::MethodLoad it'll be
a no-op. The result is that you can test your code whether it'll work on other
users machines when they get it from CPAN. The problem I'm trying to solve is
you might be unaware that some module that you use loads Apache::compat and
therefore you code works while it won't work on other setups without that bad
module which have loaded Apache::compat, even though they were asked not to.
Does it make sense? This is a sanity check tool for CPAN developers.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Making Apache::ASP optimized for mod_perl 2
Posted by Josh Chamas <jo...@chamas.com>.
Stas Bekman wrote:
>
>>> So an Apache::Common, might just be:
>>>
>>> package Apache::Common;
>>
>>
>>
>> I would suggest that Apache::Common be only the things we used to have
>> in mp1 - for example, people are used to having $r->print and
>> $r->server but $r->pool is new. even though we need pools for
>> cleanups, I think _not_ hiding it will help people migrate as well.
>
>
> As I've explained in my reply to Josh, Apache::Common won't work, as
> everybody has a different requirement from mp2. However if you want to
> provide a list of modules to load to make it work as in mp1, I think
> this is possible but the name should reflect that. For example
> Apache::LoadMP1Modules or something like that.
>
How about some importer that was function based, say...
use Apache::Loader qw(:common log_error :default you_name_it )
:common might load the LoadMP1Modules for example, or this might
just be :mp1 ... it might just be a ModPerl::Method helper ...
use ModPerl::Method qw(:mp1)
or something like that?
> No matter what conveniece helpers we provide, I'd still strongly suggest
> to CPAN authors not to use any of the helpers. Since in most cases you
> don't need all the MP1 functionality for your specific CPAN module, keep
> the list to a minimum.
>
Right. The keyword loader as above might be nice to have people specify
groups they are interested in loading like the :mp1 group assuming they
flexed most of that API.
Regards,
Josh
________________________________________________________________
Josh Chamas, Founder phone:925-552-0128
Chamas Enterprises Inc. http://www.chamas.com
NodeWorks Link Checking http://www.nodeworks.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Making Apache::ASP optimized for mod_perl 2
Posted by Stas Bekman <st...@stason.org>.
>> So an Apache::Common, might just be:
>>
>> package Apache::Common;
>
>
> I would suggest that Apache::Common be only the things we used to have
> in mp1 - for example, people are used to having $r->print and $r->server
> but $r->pool is new. even though we need pools for cleanups, I think
> _not_ hiding it will help people migrate as well.
As I've explained in my reply to Josh, Apache::Common won't work, as everybody
has a different requirement from mp2. However if you want to provide a list of
modules to load to make it work as in mp1, I think this is possible but the
name should reflect that. For example Apache::LoadMP1Modules or something like
that.
No matter what conveniece helpers we provide, I'd still strongly suggest to
CPAN authors not to use any of the helpers. Since in most cases you don't need
all the MP1 functionality for your specific CPAN module, keep the list to a
minimum.
One thing that you may not realize is that loading each new package, triggers
a load of its DSO library (foo.so). As the number of DSO files to be loaded
grows the startup slows down exponentially, because of the PIC rellocations.
So if you can keep the number of loaded DSOs down, it's a goodness.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Making Apache::ASP optimized for mod_perl 2
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>
> I don't really use that much of the Apache API, just part of what is
> exposed with the basic mod_perl 1 API. So why then would I have to
> explicitly
> load 9 separate modules?
personally, I think this is the hardest part of the migration - finding out
where all the stuff you know exists lives. it's frustrating, especially
when you _know_ the exact name of the method you need, you just can't find it.
ModPerl::MethodLookup::lookup_method() does make it a bit easier, though -
it was much harder a few months ago :)
> I was really astonished when I had to load
> Apache::Log for using log_error(), just as an example.
actually, Apache::Log is probably one of the few classes in mp1 that mimics
what mp2 does - outside of $r->log_error(), if you want to use the other
logging methods (like $r->log->error()) you need to load Apache::Log manually.
I'm only pointing this out because it was something that made me feel a
_little_ better when I was cursing all those module requirements ("oh, ok...
it was _kinda_ like this before")
>
> So how about some generic loader that loads a partial "CORE" set of
> modules, especially to help with porting like Apache::Common or some such,
> that just exposes what developers are used to programming with from mp1
> days,
> but without the full &ModPerl::MethodLookup::preload_all_modules();
we've talked about this before, and I'm still in favor of the idea (although
I was going to call it Apache::AllTheStuffGeoffWantsByDefault :)
>
> So an Apache::Common, might just be:
>
> package Apache::Common;
I would suggest that Apache::Common be only the things we used to have in
mp1 - for example, people are used to having $r->print and $r->server but
$r->pool is new. even though we need pools for cleanups, I think _not_
hiding it will help people migrate as well.
>
> use Apache::RequestRec ();
> use Apache::RequestUtil ();
> use Apache::RequestIO ();
> use Apache::Response ();
> use APR::Table ();
> use APR::Pool ();
leave APR::Pool out
> use Apache::Connection ();
> use Apache::Server ();
Apache::ServerUtil is probably a good idea as well
> use Apache::Log ();
I'm not sure about this, since the behavior differs between $r->log_error
and $r->log->error. maybe it's a good transitional class to leave out.
anyway, just some thoughts...
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Making Apache::ASP optimized for mod_perl 2
Posted by Stas Bekman <st...@stason.org>.
Josh Chamas wrote:
> Stas Bekman wrote:
>
>>>
>>> Thanks for the tip. The $ModPerl2 in this case is calculated
>>> at module load time, so I think the effect is the same, its just
>>> not a constant.
>>
>>
>>
>> The effect is very different, that's the whole point of using
>> constants. By using a constant the parser will optimize the code and
>> throw away the branches that won't be executed.
>>
>
> I have done benchmarks of constants vs. scalars, and have not seen much
> of a difference before ...
It could be insignificant, but those things add up. I believe it also saves
some memory if the branches include big chunks of code.
> I hesitate to start using constants in CPAN
> modules as I do not know how far back they go with older perls
> ( do they work for perl 5.005 ?? ), perl 5.005 would be the earliest perl
> I would support at this point if someone asked me to do so. I gave up
> on perl 5.004_04 a year to 2 back, so I am clearly slow to upgrade :)
No problem with 5.005_03:
perl-5.00503 -wle 'use constant FOO => 1; print FOO ? "OK" : "OK TOO"'
OK
>> I believe, very quickly this common thing will grow, as different
>> people have different needs and it's going to be hard to find a golden
>> middle. For example if I don't use HTTP handlers, but use mp2 to write
>> protocol modules, my common list wouldn't include any of the
>> Apache::Request* modules.
>>
>
> How about then an Apache::CommonMP1, or some such just to ease the
> compatibility thing, without the full Apache::compat, or rather an
> Apache::compat_lite ??? The very big difference being that Apache::compat
> is strong advised to not have CPAN authors use, but an Apache::CommonMP1
> might not have such an advisory. The name doesn't matter, but the effect
> does, that module authors have a nice module to load that gets them most
> of the functions that they have grown accustomed to over the years.
I like your idea in the other reply, let's discuss it there.
>> Very quickly you will find all the modules that Apache::ASP needs to
>> load and you will move on to deal with other problems. It's not like
>> you say *argh* every few minutes for the next few years to come,
>> because every time some module wasn't loaded.
>>
>
> Right, I do not make these suggestions for myself, but for those who
> will do the same as I have done, that is port larger modules
> to mp2. That was the only point of my sharing, as I have already
> solved the problem as you say. I just picture the next thousand
> people saying *argh* and thinking there might be an improvement.
I agree with you. And thanks for trying to make other developers' lives
better. I'm just trying to ensure that we give away guns which allow people
shoot themselves in their own feet only, and hopefully not wound hordes of
bypassers.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Making Apache::ASP optimized for mod_perl 2
Posted by Josh Chamas <jo...@chamas.com>.
Stas Bekman wrote:
>>
>> Thanks for the tip. The $ModPerl2 in this case is calculated
>> at module load time, so I think the effect is the same, its just
>> not a constant.
>
>
> The effect is very different, that's the whole point of using constants.
> By using a constant the parser will optimize the code and throw away the
> branches that won't be executed.
>
I have done benchmarks of constants vs. scalars, and have not seen much
of a difference before ... I hesitate to start using constants in CPAN
modules as I do not know how far back they go with older perls
( do they work for perl 5.005 ?? ), perl 5.005 would be the earliest perl
I would support at this point if someone asked me to do so. I gave up
on perl 5.004_04 a year to 2 back, so I am clearly slow to upgrade :)
>
> I believe, very quickly this common thing will grow, as different people
> have different needs and it's going to be hard to find a golden middle.
> For example if I don't use HTTP handlers, but use mp2 to write protocol
> modules, my common list wouldn't include any of the Apache::Request*
> modules.
>
How about then an Apache::CommonMP1, or some such just to ease the
compatibility thing, without the full Apache::compat, or rather an
Apache::compat_lite ??? The very big difference being that Apache::compat
is strong advised to not have CPAN authors use, but an Apache::CommonMP1
might not have such an advisory. The name doesn't matter, but the effect
does, that module authors have a nice module to load that gets them most
of the functions that they have grown accustomed to over the years.
> Very quickly you will find all the modules that Apache::ASP needs to
> load and you will move on to deal with other problems. It's not like you
> say *argh* every few minutes for the next few years to come, because
> every time some module wasn't loaded.
>
Right, I do not make these suggestions for myself, but for those who
will do the same as I have done, that is port larger modules
to mp2. That was the only point of my sharing, as I have already
solved the problem as you say. I just picture the next thousand
people saying *argh* and thinking there might be an improvement.
Regards,
Josh
________________________________________________________________
Josh Chamas, Founder phone:925-552-0128
Chamas Enterprises Inc. http://www.chamas.com
NodeWorks Link Checking http://www.nodeworks.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Making Apache::ASP optimized for mod_perl 2
Posted by Stas Bekman <st...@stason.org>.
Josh Chamas wrote:
> Stas Bekman wrote:
>
>>
>> Another minor optimization would be to use:
>>
>> use constant MODPERL2 => ...; instead of $ModPerl2
>>
>> this will save a few if() run-time checks.
>>
>
> Thanks for the tip. The $ModPerl2 in this case is calculated
> at module load time, so I think the effect is the same, its just
> not a constant.
The effect is very different, that's the whole point of using constants. By
using a constant the parser will optimize the code and throw away the branches
that won't be executed.
>> Bad programmer, no cookie ;)
>>
>> Seriously, please do not do that. Currently there are 38 Classes and
>> more will be added. You hardly need 10 or so classes. and if users
>> want some functionality in their code, they should be responsible for
>> loading it. Now if I use Apache::ASP you force the loading of all
>> modules on me, even if I don't want them and Apache::ASP doesn't use
>> even half of them.
>
>
> I don't really use that much of the Apache API, just part of what is
> exposed with the basic mod_perl 1 API. So why then would I have to
> explicitly
> load 9 separate modules? I was really astonished when I had to load
> Apache::Log for using log_error(), just as an example.
>
> So how about some generic loader that loads a partial "CORE" set of
> modules, especially to help with porting
Apache::compat does that already, since you are talking about helping with
porting. Just copy and paste a list of modules it loads, and move on.
> like Apache::Common or some such,
> that just exposes what developers are used to programming with from mp1
> days,
> but without the full &ModPerl::MethodLookup::preload_all_modules();
>
> So an Apache::Common, might just be:
>
> package Apache::Common;
>
> use Apache::RequestRec ();
> use Apache::RequestUtil ();
> use Apache::RequestIO ();
> use Apache::Response ();
> use APR::Table ();
> use APR::Pool ();
> use Apache::Connection ();
> use Apache::Server ();
> use Apache::Log ();
>
> # maybe some some others that those on the dev list would want to include?
>
> 1;
I believe, very quickly this common thing will grow, as different people have
different needs and it's going to be hard to find a golden middle. For example
if I don't use HTTP handlers, but use mp2 to write protocol modules, my common
list wouldn't include any of the Apache::Request* modules.
Very quickly you will find all the modules that Apache::ASP needs to load and
you will move on to deal with other problems. It's not like you say *argh*
every few minutes for the next few years to come, because every time some
module wasn't loaded.
mp2 is not a self contained thing, doing just a few things, as with mp1. Think
of mp2 as a much richer toolkit, that can do many things that weren't possible
with mp1. Therefore there is no longer one-fit-all solution. You choose what
modules you want to use and you use them.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Making Apache::ASP optimized for mod_perl 2
Posted by Josh Chamas <jo...@chamas.com>.
Stas Bekman wrote:
>
> Another minor optimization would be to use:
>
> use constant MODPERL2 => ...; instead of $ModPerl2
>
> this will save a few if() run-time checks.
>
Thanks for the tip. The $ModPerl2 in this case is calculated
at module load time, so I think the effect is the same, its just
not a constant.
>
> Bad programmer, no cookie ;)
>
> Seriously, please do not do that. Currently there are 38 Classes and
> more will be added. You hardly need 10 or so classes. and if users want
> some functionality in their code, they should be responsible for loading
> it. Now if I use Apache::ASP you force the loading of all modules on me,
> even if I don't want them and Apache::ASP doesn't use even half of them.
I don't really use that much of the Apache API, just part of what is
exposed with the basic mod_perl 1 API. So why then would I have to explicitly
load 9 separate modules? I was really astonished when I had to load
Apache::Log for using log_error(), just as an example.
So how about some generic loader that loads a partial "CORE" set of
modules, especially to help with porting like Apache::Common or some such,
that just exposes what developers are used to programming with from mp1 days,
but without the full &ModPerl::MethodLookup::preload_all_modules();
So an Apache::Common, might just be:
package Apache::Common;
use Apache::RequestRec ();
use Apache::RequestUtil ();
use Apache::RequestIO ();
use Apache::Response ();
use APR::Table ();
use APR::Pool ();
use Apache::Connection ();
use Apache::Server ();
use Apache::Log ();
# maybe some some others that those on the dev list would want to include?
1;
>
> Yes, perl-5.8.0 w/ ithreads and w/o them have quite a big performance
> differences as it was pointed out several times on the p5p list. I think
> you should benchmark perl-5.8.0 w/o threads against mp1 and mp1/prefork
> to make the benchmark fair.
>
That is a good point. Thanks.
Regards,
Josh
________________________________________________________________
Josh Chamas, Founder phone:925-552-0128
Chamas Enterprises Inc. http://www.chamas.com
NodeWorks Link Checking http://www.nodeworks.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Making Apache::ASP optimized for mod_perl 2
Posted by Stas Bekman <st...@stason.org>.
Josh Chamas wrote:
> Hey,
>
> I just wanted to share my experience with making Apache::ASP
> not use Apache::compat to run under mod_perl 2 ( 1.99_09 actually ).
> Keeping Apache::ASP running under mod_perl 1 is important, so part
> of the effort was to minimize code impact on ASP, while using the
> correct APIs under mp2. I expect this work to be available for the
> Apache::ASP 2.55 release, but this is still in development.
>
> What I found was that the only APIs that I needed to trigger off of
> a MP2 type constant was register_cleanup and send_http_header.
> Following the example of Apache::compat, I basically did these things:
>
> if($ModPerl2) {
Another minor optimization would be to use:
use constant MODPERL2 => ...; instead of $ModPerl2
this will save a few if() run-time checks.
> Besides not using Apache::compat, I tried also to not
>
> &ModPerl::MethodLookup::preload_all_modules();
>
> but ended up leaving it in because Apache::ASP uses so much of the
> Apache API, via these necessary modules...
>
> Apache::RequestRec
> Apache::RequestUtil
> Apache::RequestIO
> Apache::Response
> APR::Table
> APR::Pool
> Apache::Connection
> Apache::Server
> Apache::Log
>
> that the savings in memory did not warrant explicitly listing just these
> modules for loading. The savings was between 500K-2M post benchmark run
> by explicitly loading, and I don't want to run the risk that I missed
> some obscure Apache API code reference that comes up only rarely at
> runtime,
> so I'll load in all the modules for now.
Bad programmer, no cookie ;)
Seriously, please do not do that. Currently there are 38 Classes and more will
be added. You hardly need 10 or so classes. and if users want some
functionality in their code, they should be responsible for loading it. Now if
I use Apache::ASP you force the loading of all modules on me, even if I don't
want them and Apache::ASP doesn't use even half of them. This is the same
problem as with Apache::compat. These tools are there to easy the porting, but
not for use by CPAN modules. It'll also have side effects on your users, since
once they load Apache::ASP they won't have a need to load modules anymore,
since everything will be loaded. Once they move their code elsewhere without
Apache::ASP, their code will suddenly won't work anymore.
> I also managed to get Apache::ASP working under modperl handler config
> for an extra 5-10% performance speedup.
>
> At the end of all this, I am finding that despite my best efforts,
> Apache::ASP
> runs some 30-40% slower under Apache2/mp2 than Apache1/mp1. Though both
> perls
> are perl 5.8, a big difference is that for mp2 the perl has usethreads
> defined,
> but the perl 5.8 for mp1 does not. Maybe the thread layer has to do
> with the
> slower performance? I believe that having the thread layer on for eventual
> use of the Apache 2 worker mpm is essential, so this is why I compiled perl
> that way for benchmarking.
Yes, perl-5.8.0 w/ ithreads and w/o them have quite a big performance
differences as it was pointed out several times on the p5p list. I think you
should benchmark perl-5.8.0 w/o threads against mp1 and mp1/prefork to make
the benchmark fair.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: [mp2] Making Apache::ASP optimized for mod_perl 2
Posted by Stas Bekman <st...@stason.org>.
Josh Chamas wrote:
> Hey,
>
> I just wanted to share my experience with making Apache::ASP
> not use Apache::compat to run under mod_perl 2 ( 1.99_09 actually ).
> Keeping Apache::ASP running under mod_perl 1 is important, so part
> of the effort was to minimize code impact on ASP, while using the
> correct APIs under mp2. I expect this work to be available for the
> Apache::ASP 2.55 release, but this is still in development.
>
> What I found was that the only APIs that I needed to trigger off of
> a MP2 type constant was register_cleanup and send_http_header.
> Following the example of Apache::compat, I basically did these things:
>
> if($ModPerl2) {
Another minor optimization would be to use:
use constant MODPERL2 => ...; instead of $ModPerl2
this will save a few if() run-time checks.
> Besides not using Apache::compat, I tried also to not
>
> &ModPerl::MethodLookup::preload_all_modules();
>
> but ended up leaving it in because Apache::ASP uses so much of the
> Apache API, via these necessary modules...
>
> Apache::RequestRec
> Apache::RequestUtil
> Apache::RequestIO
> Apache::Response
> APR::Table
> APR::Pool
> Apache::Connection
> Apache::Server
> Apache::Log
>
> that the savings in memory did not warrant explicitly listing just these
> modules for loading. The savings was between 500K-2M post benchmark run
> by explicitly loading, and I don't want to run the risk that I missed
> some obscure Apache API code reference that comes up only rarely at
> runtime,
> so I'll load in all the modules for now.
Bad programmer, no cookie ;)
Seriously, please do not do that. Currently there are 38 Classes and more will
be added. You hardly need 10 or so classes. and if users want some
functionality in their code, they should be responsible for loading it. Now if
I use Apache::ASP you force the loading of all modules on me, even if I don't
want them and Apache::ASP doesn't use even half of them. This is the same
problem as with Apache::compat. These tools are there to easy the porting, but
not for use by CPAN modules. It'll also have side effects on your users, since
once they load Apache::ASP they won't have a need to load modules anymore,
since everything will be loaded. Once they move their code elsewhere without
Apache::ASP, their code will suddenly won't work anymore.
> I also managed to get Apache::ASP working under modperl handler config
> for an extra 5-10% performance speedup.
>
> At the end of all this, I am finding that despite my best efforts,
> Apache::ASP
> runs some 30-40% slower under Apache2/mp2 than Apache1/mp1. Though both
> perls
> are perl 5.8, a big difference is that for mp2 the perl has usethreads
> defined,
> but the perl 5.8 for mp1 does not. Maybe the thread layer has to do
> with the
> slower performance? I believe that having the thread layer on for eventual
> use of the Apache 2 worker mpm is essential, so this is why I compiled perl
> that way for benchmarking.
Yes, perl-5.8.0 w/ ithreads and w/o them have quite a big performance
differences as it was pointed out several times on the p5p list. I think you
should benchmark perl-5.8.0 w/o threads against mp1 and mp1/prefork to make
the benchmark fair.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com