You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2003/11/04 20:40:54 UTC
[mp2] perl_clone takes 5 and more seconds to complete
I've noticed earlier that the new ithreads test take ages to run. Because by
the time they run the interpreter has about 150 modules loaded, and it takes
ages to perl_clone() a new ithread.
Now I always wondered why it takes 30-60 and more seconds for the test suite
to start under worker mpm, compared to just about 10 for prefork mpm. I did a
simple
# term1
% tail -F t/logs/error_log
# term2
% env MOD_PERL_TRACE=all t/TEST -start
and voila, you can see with unarmed eye that we spend 5 seconds and more time
(depending on your CPU) in each call to modperl_interp_new() and there are
several of these calls. Looks very impractical to me.
Applying a simple trace to modperl_interp.c:
+ MP_TRACE_i(MP_FUNC, "perl_clone start\n");
interp->perl = perl_clone(perl, clone_flags);
+ MP_TRACE_i(MP_FUNC, "perl_clone end\n");
easily shows that perl_clone() is the one that takes an impractical amount of
time to complete.
Where does this bring us? When a new request is coming in and all interpreters
are busy and the pool quota is not full, a new interepreter will be cloned.
And your request will be served in 6-10 secs instead of 50msecs. Now imagine a
busy webserver with no spare CPU cycles, perl_clone may take 20 secs and more.
Indeed running in parallel 'perl -le 'do { $a=5; $b = $a**5 } while 1' slows
perl_clone twice. Running a few of those CPU hogs, slows it down by the number
of processes fighting for CPU slices.
I hope I'm not crying wolf and things are better than what I see them, please
tell me that I'm totally wrong.
The only bright side I can see at the moment is that most people won't have
150 modules loaded. But 50 modules will scale bad enough.
Randy, do you see the same slow behavior under win32? I expect it to be the case.
__________________________________________________________________
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] perl_clone takes 5 and more seconds to complete
Posted by Perrin Harkins <pe...@elem.com>.
On Wed, 2003-11-05 at 09:37, Vivek Khera wrote:
> Well, that would make for an argument to scale your hardware to match
> your expectations and load. You can't make your hardware run more
> than 100% unless you switch worlds over to Star Trek...
Not even:
"I can't change the laws of physics, Captain!" -- Scotty
> It kind of makes you
> rethink the whole 'threads are better than processes' debate if your
> threads are more heavy-weight than processes ;-)
Yes, Perl threads do not perform well at this point. Unfortunately,
they seem to be necessary for playing well with a threaded HTTP server.
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] perl_clone takes 5 and more seconds to complete
Posted by Elizabeth Mattijsen <li...@dijkmat.nl>.
At 09:37 -0500 11/5/03, Vivek Khera wrote:
> >>>>> "SB" == Stas Bekman <st...@stason.org> writes:
>SB> Where does this bring us? When a new request is coming in and all
>SB> interpreters are busy and the pool quota is not full, a new
>SB> interepreter will be cloned. And your request will be served in
>SB> 6-10 secs instead of 50msecs. Now imagine a busy webserver with no
>Anyhow, why would it take so long to clone a thread? Is perl chasing
>down every single memory pointer or something?
Yes. And every shared variable lives inside each thread as a tied
variable with its CPU and memory overhead. And inside a hidden
thread.
>It kind of makes you
>rethink the whole 'threads are better than processes' debate if your
>threads are more heavy-weight than processes ;-)
Hence forks.pm ;-)
Liz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] perl_clone takes 5 and more seconds to complete
Posted by Vivek Khera <kh...@kcilink.com>.
>>>>> "SB" == Stas Bekman <st...@stason.org> writes:
SB> Where does this bring us? When a new request is coming in and all
SB> interpreters are busy and the pool quota is not full, a new
SB> interepreter will be cloned. And your request will be served in
SB> 6-10 secs instead of 50msecs. Now imagine a busy webserver with no
Well, that would make for an argument to scale your hardware to match
your expectations and load. You can't make your hardware run more
than 100% unless you switch worlds over to Star Trek...
Anyhow, why would it take so long to clone a thread? Is perl chasing
down every single memory pointer or something? It kind of makes you
rethink the whole 'threads are better than processes' debate if your
threads are more heavy-weight than processes ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] perl_clone takes 5 and more seconds to complete
Posted by Stas Bekman <st...@stason.org>.
Hmm, sent to the old address Arthur Bergman <ar...@contiller.se>
Rafael Garcia-Suarez wrote:
> Stas Bekman wrote:
>
>>The problem is that it's not under our control. The slow part is perl_clone,
>>which is a perl API. It's slow because it takes time to clone all the
>>non-mutable data. Nick has been working on COW (Copy-On-Write), but from his
>>reports it doesn't seem to give much speedup if at all.
>
>
> If I'm understanding correctly, Arthur Bergman is working on a COW overhaul
> which may make the situation better. (We haven't seen his patch yet.)
Arthur, do you have any updates on this issue?
__________________________________________________________________
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] perl_clone takes 5 and more seconds to complete
Posted by Stas Bekman <st...@stason.org>.
Rafael Garcia-Suarez wrote:
> Stas Bekman wrote:
>
>>The problem is that it's not under our control. The slow part is perl_clone,
>>which is a perl API. It's slow because it takes time to clone all the
>>non-mutable data. Nick has been working on COW (Copy-On-Write), but from his
>>reports it doesn't seem to give much speedup if at all.
>
>
> If I'm understanding correctly, Arthur Bergman is working on a COW overhaul
> which may make the situation better. (We haven't seen his patch yet.)
Arthur, do you have any updates on this issue?
__________________________________________________________________
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] perl_clone takes 5 and more seconds to complete
Posted by Rafael Garcia-Suarez <ra...@hexaflux.com>.
Stas Bekman wrote:
> The problem is that it's not under our control. The slow part is perl_clone,
> which is a perl API. It's slow because it takes time to clone all the
> non-mutable data. Nick has been working on COW (Copy-On-Write), but from his
> reports it doesn't seem to give much speedup if at all.
If I'm understanding correctly, Arthur Bergman is working on a COW overhaul
which may make the situation better. (We haven't seen his patch yet.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] perl_clone takes 5 and more seconds to complete
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>> Applying a simple trace to modperl_interp.c:
>>
>> + MP_TRACE_i(MP_FUNC, "perl_clone start\n");
>> interp->perl = perl_clone(perl, clone_flags);
>> + MP_TRACE_i(MP_FUNC, "perl_clone end\n");
>>
>> easily shows that perl_clone() is the one that takes an impractical
>> amount of time to complete.
>>
>> Where does this bring us? When a new request is coming in and all
>> interpreters are busy and the pool quota is not full, a new
>> interepreter will be cloned. And your request will be served in 6-10
>> secs instead of 50msecs. Now imagine a busy webserver with no spare
>> CPU cycles, perl_clone may take 20 secs and more.
>
>
> I certainly don't disagree with you that this is not ideal and we ought
> to improve it if we can.
The problem is that it's not under our control. The slow part is perl_clone,
which is a perl API. It's slow because it takes time to clone all the
non-mutable data. Nick has been working on COW (Copy-On-Write), but from his
reports it doesn't seem to give much speedup if at all.
> however, what this means to me is that you need to tweak and tune a
> threaded mpm - namely PerlInterpMinSpare - just like you do prefork if
> you don't want your application to suffer. I know lots of people were
> hoping that the threaded mpms would improve performance by mere virtue
> of the reduced process size, but I guess there is a trade-off in that.
Yup. The only way I see it working well is by using dedicated pools for each
separate application which uses its own modules, not overlapping with other apps.
__________________________________________________________________
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] perl_clone takes 5 and more seconds to complete
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Applying a simple trace to modperl_interp.c:
>
> + MP_TRACE_i(MP_FUNC, "perl_clone start\n");
> interp->perl = perl_clone(perl, clone_flags);
> + MP_TRACE_i(MP_FUNC, "perl_clone end\n");
>
> easily shows that perl_clone() is the one that takes an impractical
> amount of time to complete.
>
> Where does this bring us? When a new request is coming in and all
> interpreters are busy and the pool quota is not full, a new interepreter
> will be cloned. And your request will be served in 6-10 secs instead of
> 50msecs. Now imagine a busy webserver with no spare CPU cycles,
> perl_clone may take 20 secs and more.
I certainly don't disagree with you that this is not ideal and we ought to
improve it if we can.
however, what this means to me is that you need to tweak and tune a threaded
mpm - namely PerlInterpMinSpare - just like you do prefork if you don't want
your application to suffer. I know lots of people were hoping that the
threaded mpms would improve performance by mere virtue of the reduced
process size, but I guess there is a trade-off in that.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] perl_clone takes 5 and more seconds to complete
Posted by Elizabeth Mattijsen <li...@dijkmat.nl>.
At 10:58 -0500 11/12/03, Geoffrey Young wrote:
>Rafael Garcia-Suarez wrote:
>>Geoffrey Young wrote:
>>>the problem with this, though, is that we don't really want a
>>>clean interpreter, we want an _almost_ clean one - one with only
>>>the data we know is important (like the globals set within the
>>><Perl> section). so, if we could copy the relevant data from the
>>>first interpreter and insert it into the one we're about to clone
>>>for the request, we'd have the best situation possible - minimal
>>>data in the parent interpreter.
>>Problem : how to separate the relevant data from the irrelevant one ?
>>Does it live in a particular package ?
>for the <Perl> stuff I was talking about, I believe so. however,
>for directive handlers it does not, so we'd probably need to tweak
>the interface a bit.
>but the idea, I guess, is that mod_perl would (eventually) know what
>data is required to be copied, so long as we had a way to do it.
Wouldn't Storable or Data::Dumper be able to do such a thing? At the
end of config, dump the pertinent bits to memory (or possibly even a
file), and then read them back in the other interpreter?
Liz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] perl_clone takes 5 and more seconds to complete
Posted by Elizabeth Mattijsen <li...@dijkmat.nl>.
At 09:53 -0800 11/13/03, Stas Bekman wrote:
>Elizabeth Mattijsen wrote:
> > Wouldn't Storable or Data::Dumper be able to do such a thing? At the
>> end of config, dump the pertinent bits to memory (or possibly even a
> > file), and then read them back in the other interpreter?
>I'm not sure as those bits include references to internal C structs.
Ok, that's out of the question, then...
Liz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] perl_clone takes 5 and more seconds to complete
Posted by Stas Bekman <st...@stason.org>.
Elizabeth Mattijsen wrote:
> At 18:06 -0800 11/12/03, Stas Bekman wrote:
>
>> Geoffrey Young wrote:
>>
>>> for the <Perl> stuff I was talking about, I believe so. however, for
>>> directive handlers it does not, so we'd probably need to tweak the
>>> interface a bit.
>>
>> And not for <Perl>, because a random code can be run there in random
>> packages.
>
>
> But you could document that only the "real" config bits would be
> available later and anything else lost (unless re-required later). And
> copy the config bits in a Storable / Data::Dumper format between the
> interpreters. This is not too dissimilar to what forks.pm does for
> shared variables and Thread::Tie does.
Even we did enforce that, we still have things like PerlLoadModule which
extend the config directives dictionary.
>> for the <Perl> stuff I was talking about, I believe so. however, for
>> directive handlers it does not, so we'd probably need to tweak the
>> interface a bit.
>> but the idea, I guess, is that mod_perl would (eventually) know what
>> data is required to be copied, so long as we had a way to do it.
>
>
> Wouldn't Storable or Data::Dumper be able to do such a thing? At the
> end of config, dump the pertinent bits to memory (or possibly even a
> file), and then read them back in the other interpreter?
I'm not sure as those bits include references to internal C structs.
__________________________________________________________________
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] perl_clone takes 5 and more seconds to complete
Posted by Elizabeth Mattijsen <li...@dijkmat.nl>.
At 18:06 -0800 11/12/03, Stas Bekman wrote:
>Geoffrey Young wrote:
>>for the <Perl> stuff I was talking about, I believe so. however,
>>for directive handlers it does not, so we'd probably need to tweak
>>the interface a bit.
>And not for <Perl>, because a random code can be run there in random packages.
But you could document that only the "real" config bits would be
available later and anything else lost (unless re-required later).
And copy the config bits in a Storable / Data::Dumper format between
the interpreters. This is not too dissimilar to what forks.pm does
for shared variables and Thread::Tie does.
Liz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] perl_clone takes 5 and more seconds to complete
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>
> Rafael Garcia-Suarez wrote:
>
>> Geoffrey Young wrote:
>>
>>> the problem with this, though, is that we don't really want a clean
>>> interpreter, we want an _almost_ clean one - one with only the data
>>> we know is important (like the globals set within the <Perl>
>>> section). so, if we could copy the relevant data from the first
>>> interpreter and insert it into the one we're about to clone for the
>>> request, we'd have the best situation possible - minimal data in the
>>> parent interpreter.
>>
>>
>>
>> Problem : how to separate the relevant data from the irrelevant one ?
>> Does it live in a particular package ?
>
>
> for the <Perl> stuff I was talking about, I believe so. however, for
> directive handlers it does not, so we'd probably need to tweak the
> interface a bit.
And not for <Perl>, because a random code can be run there in random packages.
> but the idea, I guess, is that mod_perl would (eventually) know what
> data is required to be copied, so long as we had a way to do it.
That's why I was talking about diffing the Optree before and after the config
phase.
>> I imagine it's possible to e.g. add an attribute on stashes that say
>> "don't clone me". And implement a function
>> "require_for_this_interpreter_only $module"
>> in an XS module.
which goes back to the problem of being able to do it dynamically, i.e. sort
of doing the diff I'm talking about above.
__________________________________________________________________
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] perl_clone takes 5 and more seconds to complete
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Rafael Garcia-Suarez wrote:
> Geoffrey Young wrote:
>
>>the problem with this, though, is that we don't really want a clean
>>interpreter, we want an _almost_ clean one - one with only the data we know
>>is important (like the globals set within the <Perl> section). so, if we
>>could copy the relevant data from the first interpreter and insert it into
>>the one we're about to clone for the request, we'd have the best situation
>>possible - minimal data in the parent interpreter.
>
>
> Problem : how to separate the relevant data from the irrelevant one ?
> Does it live in a particular package ?
for the <Perl> stuff I was talking about, I believe so. however, for
directive handlers it does not, so we'd probably need to tweak the interface
a bit.
but the idea, I guess, is that mod_perl would (eventually) know what data is
required to be copied, so long as we had a way to do it.
>
> I imagine it's possible to e.g. add an attribute on stashes that say
> "don't clone me". And implement a function "require_for_this_interpreter_only $module"
> in an XS module.
cool :)
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] perl_clone takes 5 and more seconds to complete
Posted by Rafael Garcia-Suarez <ra...@hexaflux.com>.
Geoffrey Young wrote:
>
> the problem with this, though, is that we don't really want a clean
> interpreter, we want an _almost_ clean one - one with only the data we know
> is important (like the globals set within the <Perl> section). so, if we
> could copy the relevant data from the first interpreter and insert it into
> the one we're about to clone for the request, we'd have the best situation
> possible - minimal data in the parent interpreter.
Problem : how to separate the relevant data from the irrelevant one ?
Does it live in a particular package ?
I imagine it's possible to e.g. add an attribute on stashes that say
"don't clone me". And implement a function "require_for_this_interpreter_only $module"
in an XS module.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] perl_clone takes 5 and more seconds to complete
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Rafael Garcia-Suarez wrote:
> Stas Bekman wrote:
>
>>I'm not talking about mod_perl internals, just talking about amputating a
>>chunk of the Optree from one interpreter and replanting it into another
>>interpreter (not perl_cloned one).
>
>
> You need to explain to me what those interpreters are. IIUC from your
> remark below the first one is in the root httpd process to parse the
> config file ; the other ones are in the child httpd processes to process
> requests ? And you want to slim down the first one ? What are the CV
> root and CV start of those interpreters ?
>
> Why do you want to move CVs from the first one to the later ones ? Just
> removing them from the first one is not enough ?
here is an idea of what we're talking about.
httpd.conf hits a <Perl> section, so mod_perl needs to launch the
interpreter. the <Perl> section adds configuration directives httpd.conf
and sets $Apache::Server::SaveConfig = 1, which means that the configuration
is to be available via perl package variables at request time.
so, when this interpreter is cloned so a pool of them can service requests,
that data needs to go with it . under the current situation, this all
happens just fine, since clones carry with them copies of everything (or so
I read :)
however, because the interpreter was started when <Perl> was parsed, any
modules that are use()d after the interpreter gets started (via startup.pl,
PerlModule, or whatever) are _also_ added to the interpreter and copied.
this is bad for a few reasons, namely that request-time processing may not
need the packages (if they were used only for config parsing), and that the
interpreter cloning required when the request pool is expanded takes an
extremely long time.
so, what would be ideal is to clone a _different_ interpreter than the one
that parsed <Perl>, thus giving us the ability to clone an interpreter with
no loaded modules at all. this would greatly reduce the time it takes to
clone interpreters for the request pool, thus increasing request-time
performance.
the problem with this, though, is that we don't really want a clean
interpreter, we want an _almost_ clean one - one with only the data we know
is important (like the globals set within the <Perl> section). so, if we
could copy the relevant data from the first interpreter and insert it into
the one we're about to clone for the request, we'd have the best situation
possible - minimal data in the parent interpreter.
or something like that :)
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] perl_clone takes 5 and more seconds to complete
Posted by Rafael Garcia-Suarez <ra...@hexaflux.com>.
Stas Bekman wrote:
>
> I'm not talking about mod_perl internals, just talking about amputating a
> chunk of the Optree from one interpreter and replanting it into another
> interpreter (not perl_cloned one).
You need to explain to me what those interpreters are. IIUC from your
remark below the first one is in the root httpd process to parse the
config file ; the other ones are in the child httpd processes to process
requests ? And you want to slim down the first one ? What are the CV
root and CV start of those interpreters ?
Why do you want to move CVs from the first one to the later ones ? Just
removing them from the first one is not enough ?
> I'm not sure whether this is possible at
> all. I really want some sort of Storable::freeze, so I can save a CV and all
> the related SVs and then resurrect them with ::thaw in another interpreter.
The relative SVs ? did you mean the whole contents of stashes and lexical pads ?
> To repeat, the problem we have is that we start perl early to do config
> parsing (.e.g code run in <Perl> sections) and we really want to kill that
> perl when it finished dealing with config, but we need the perl data it
> generated to be resurrected in the perl that will process the requests.
The whole data+cv moving is theoretically possible but I'm not convinced there
will be a significant performance gain.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] perl_clone takes 5 and more seconds to complete
Posted by Stas Bekman <st...@stason.org>.
Rafael Garcia-Suarez wrote:
> Stas Bekman wrote:
>
>>How about this (yet another) idea. Snapshot the OpCode tree before and after
>>running the <Perl> sections (or PerlLoadModule). Then traverse both OpCode
>>trees and somehow rip off the differences and transplant them into the newly
>>perl_clone()'d interpreters. We prefer to sustain a delay at the startup,
>>versus run-time. Any surgeons out there?
>
>
> I'm not sure what you mean there (lack of knowledge of mod_perl internals),
> but the optrees aren't cloned, be it the main optree or the CV optrees.
I'm not talking about mod_perl internals, just talking about amputating a
chunk of the Optree from one interpreter and replanting it into another
interpreter (not perl_cloned one). I'm not sure whether this is possible at
all. I really want some sort of Storable::freeze, so I can save a CV and all
the related SVs and then resurrect them with ::thaw in another interpreter.
To repeat, the problem we have is that we start perl early to do config
parsing (.e.g code run in <Perl> sections) and we really want to kill that
perl when it finished dealing with config, but we need the perl data it
generated to be resurrected in the perl that will process the requests.
__________________________________________________________________
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] perl_clone takes 5 and more seconds to complete
Posted by Rafael Garcia-Suarez <ra...@hexaflux.com>.
Stas Bekman wrote:
>
> How about this (yet another) idea. Snapshot the OpCode tree before and after
> running the <Perl> sections (or PerlLoadModule). Then traverse both OpCode
> trees and somehow rip off the differences and transplant them into the newly
> perl_clone()'d interpreters. We prefer to sustain a delay at the startup,
> versus run-time. Any surgeons out there?
I'm not sure what you mean there (lack of knowledge of mod_perl internals),
but the optrees aren't cloned, be it the main optree or the CV optrees.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] perl_clone takes 5 and more seconds to complete
Posted by Stas Bekman <st...@stason.org>.
Rafael Garcia-Suarez wrote:
> Stas Bekman wrote:
>
>>I've suggested that long time ago and we have discussed the idea here. It
>>can't work the way you (and I) suggested. Since PerlLoadModule loads things
>>into *the* interpreter that you will need to access later during the request
>>time. Same goes for <Perl>. What you really need is to be able to rip off
>>those wanted at run-time chunks of the OpCode tree and re-plant them into the
>>new interepreters. It's quite possible that we could do that but I don't think
>>we have the easy way to do it now. We can certainly manipulate the tree with
>>B::Generate (see Simon Cozen's paper in TPC proceedings 2001 [1], which was
>>about manipulating the OpCode tree) and do selective copying (transplanting).
>
>
> Fudging with the optree is probably not the way to go. I think that what
> you want, if I understand correctly, is moving stashes into new
> interpreters. CVs live in stashes and maintain a pointer to the optree
> that implements them. And the bulks of ops are in subroutines.
>
> Moving CVs won't be straightforward, though, because you need to watch
> out for closures (CvOUTSIDE).
Yup, that was the (theorethical) idea. I'm not sure how practical it is.
How about this (yet another) idea. Snapshot the OpCode tree before and after
running the <Perl> sections (or PerlLoadModule). Then traverse both OpCode
trees and somehow rip off the differences and transplant them into the newly
perl_clone()'d interpreters. We prefer to sustain a delay at the startup,
versus run-time. Any surgeons out there?
__________________________________________________________________
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] perl_clone takes 5 and more seconds to complete
Posted by Rafael Garcia-Suarez <ra...@hexaflux.com>.
Stas Bekman wrote:
>
> I've suggested that long time ago and we have discussed the idea here. It
> can't work the way you (and I) suggested. Since PerlLoadModule loads things
> into *the* interpreter that you will need to access later during the request
> time. Same goes for <Perl>. What you really need is to be able to rip off
> those wanted at run-time chunks of the OpCode tree and re-plant them into the
> new interepreters. It's quite possible that we could do that but I don't think
> we have the easy way to do it now. We can certainly manipulate the tree with
> B::Generate (see Simon Cozen's paper in TPC proceedings 2001 [1], which was
> about manipulating the OpCode tree) and do selective copying (transplanting).
Fudging with the optree is probably not the way to go. I think that what
you want, if I understand correctly, is moving stashes into new
interpreters. CVs live in stashes and maintain a pointer to the optree
that implements them. And the bulks of ops are in subroutines.
Moving CVs won't be straightforward, though, because you need to watch
out for closures (CvOUTSIDE).
> 1 - I couldn't find the proceeding paper online, but this article seems to be
> pretty close (same?) to the original paper:
> http://www.perl.com/lpt/a/2002/05/07/optree.html
> Highly recommended.
>
> p.s. and there is also the optimizer which we may find useful in our game:
> http://archive.develooper.com/perl6-internals@perl.org/msg03732.html?x
>
> p.p.s.: google came up with the following interesting resources:
> http://wiki.slowass.net/?PerlAssembly
> http://www.faqs.org/docs/perl5int/compiler.html
See also the perlcompile man page.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] perl_clone takes 5 and more seconds to complete
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
[...]
>>> So, in the worker mpm, you need to load as little as possible before
>>> cloning, and only load modules when they are really needed inside the
>>> thread. This is perpendicular to prefork mpm, where you want to load
>>> as much as possible beforehand.
>>
>>
>>
>> The problem is with 3rd party modules, which may load things they may
>> never use, by calling 'use module' on the top, instead of calling
>> 'require module' where it's really needed. So you end up with dozens
>> of modules loaded that you don't really use. Too bad we can't unload
>> modules.
>
>
> it seems to me it doesn't need to be this way.
>
> I haven't looked at the interpreter pool code (and probably wouldn't get
> it anyway) but I'm wondering if we can't improve things on our side a
> bit just by juggling things around some. so, if you can follow my
> stream of consciousness for a moment... :)
>
> the first thing that jumps to mind is that PerlModule inclusion is
> already delayed. so, theoretically, we could delay that inclusion until
> after the interpreter is cloned, right? that's essentially what Liz
> says is the best solution in her article. have the inclusion be the
> first thing an interpreter does when it's added to the pool, before it's
> available for use?
>
> in practice, where this might be a problem is that the interpreter can
> be started early due to <Perl> sections, etc. I've been wondering for a
> while now if it's required that we clone _this_ interpreter. that is,
> why can't we have PerlSwitches -T work even if <Perl> starts _an_
> interpreter - why not fork (or something) off a separate perl process
> for httpd.conf-related things then clone the (prisine, lightweight)
> interpreter after parsing? or something like that :)
>
> what I'm getting at (without a full understanding of the issues
> involved) is that we probably can be a bit smarter about this if we
> redesign things a bit, knowing now what the issues are. and it seems
> like we're already part of the way there with the way PerlModule already
> behaves.
>
> just some random thoughts...
I've suggested that long time ago and we have discussed the idea here. It
can't work the way you (and I) suggested. Since PerlLoadModule loads things
into *the* interpreter that you will need to access later during the request
time. Same goes for <Perl>. What you really need is to be able to rip off
those wanted at run-time chunks of the OpCode tree and re-plant them into the
new interepreters. It's quite possible that we could do that but I don't think
we have the easy way to do it now. We can certainly manipulate the tree with
B::Generate (see Simon Cozen's paper in TPC proceedings 2001 [1], which was
about manipulating the OpCode tree) and do selective copying (transplanting).
1 - I couldn't find the proceeding paper online, but this article seems to be
pretty close (same?) to the original paper:
http://www.perl.com/lpt/a/2002/05/07/optree.html
Highly recommended.
p.s. and there is also the optimizer which we may find useful in our game:
http://archive.develooper.com/perl6-internals@perl.org/msg03732.html?x
p.p.s.: google came up with the following interesting resources:
http://wiki.slowass.net/?PerlAssembly
http://www.faqs.org/docs/perl5int/compiler.html
__________________________________________________________________
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] perl_clone takes 5 and more seconds to complete
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>> This may be old news to some, but I wrote an article about this about
>> two months ago on Perlmonks: Things you need to know before
>> programming Perl ithreads.
>>
>> http://www.perlmonks.org/index.pl?node_id=288022
>
>
> Yup, you kindly pointed me to it when you wrote it. It's a very good
> article.
I hadn't seen it yet - thanks for pointing it out.
>
>> So, in the worker mpm, you need to load as little as possible before
>> cloning, and only load modules when they are really needed inside the
>> thread. This is perpendicular to prefork mpm, where you want to load
>> as much as possible beforehand.
>
>
> The problem is with 3rd party modules, which may load things they may
> never use, by calling 'use module' on the top, instead of calling
> 'require module' where it's really needed. So you end up with dozens of
> modules loaded that you don't really use. Too bad we can't unload modules.
it seems to me it doesn't need to be this way.
I haven't looked at the interpreter pool code (and probably wouldn't get it
anyway) but I'm wondering if we can't improve things on our side a bit just
by juggling things around some. so, if you can follow my stream of
consciousness for a moment... :)
the first thing that jumps to mind is that PerlModule inclusion is already
delayed. so, theoretically, we could delay that inclusion until after the
interpreter is cloned, right? that's essentially what Liz says is the best
solution in her article. have the inclusion be the first thing an
interpreter does when it's added to the pool, before it's available for use?
in practice, where this might be a problem is that the interpreter can be
started early due to <Perl> sections, etc. I've been wondering for a while
now if it's required that we clone _this_ interpreter. that is, why can't
we have PerlSwitches -T work even if <Perl> starts _an_ interpreter - why
not fork (or something) off a separate perl process for httpd.conf-related
things then clone the (prisine, lightweight) interpreter after parsing? or
something like that :)
what I'm getting at (without a full understanding of the issues involved) is
that we probably can be a bit smarter about this if we redesign things a
bit, knowing now what the issues are. and it seems like we're already part
of the way there with the way PerlModule already behaves.
just some random thoughts...
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] perl_clone takes 5 and more seconds to complete
Posted by Stas Bekman <st...@stason.org>.
Elizabeth Mattijsen wrote:
> At 11:40 -0800 11/4/03, Stas Bekman wrote:
>
>> The only bright side I can see at the moment is that most people won't
>> have 150 modules loaded. But 50 modules will scale bad enough.
>
>
> Agree. Which is why I think you really will have to know what you're
> doing if you want to use mod_perl with a worker mpm.
But it's not an option on win32 platforms :( We just hoped that mp2 for the
first time will make win32 as a viable platform for modperl...
> This may be old news to some, but I wrote an article about this about
> two months ago on Perlmonks: Things you need to know before programming
> Perl ithreads.
>
> http://www.perlmonks.org/index.pl?node_id=288022
Yup, you kindly pointed me to it when you wrote it. It's a very good article.
> So, in the worker mpm, you need to load as little as possible before
> cloning, and only load modules when they are really needed inside the
> thread. This is perpendicular to prefork mpm, where you want to load as
> much as possible beforehand.
The problem is with 3rd party modules, which may load things they may never
use, by calling 'use module' on the top, instead of calling 'require module'
where it's really needed. So you end up with dozens of modules loaded that you
don't really use. Too bad we can't unload modules.
> One of my related projects is load.pm (on CPAN) which is an AutoLoader
> type module with a twist. It allows for a more flexible way of loading
> modules. It allows external control over whether a module will load
> subroutines on demand or all subroutines at once. In a worker mpm you
> would want on demand loading, for a prefork mpm you'd want it all at once.
You have at least one problem to deal with, subs that get "autovivified" from
air at 'require module' time. e.g. look at Apache::TestTrace -- it creates a
whole bunch of subs on the fly.
> As my plan for world domination, all core modules should use "load.pm",
> or the load.pm functionality should somehow become part of interpreter.
> I'd appreciate feedback whether this is a good idea, or just a delusion
> of grandeur on my part. ;-)
You give us too little details to give you a constructive feedback, Liz.
What I'd like to see is this. overload require and register all the used
modules (I think James Smith wrote such a module, Module::Info?) then get the
stats on which modules are really used by running coverage testing (hopefully
covering all possible paths, including erroneous ones). Next instruct
require() to ignore any requests to load modules which weren't used so far,
returning success to the caller. The implementation seems to be easy, the hard
part would be to come with coverage tests, and most people will fail to do
that, which renders my idea not so practical...
I don't know if trying to go into the guts and prune the unused OpCode tree
chunks will help. e.g. add a new new flag to each CODE opcode telling whether
it was used or not. then if it wasn't purge it or don't clone it... I guess
that's what COW will do more or less...
__________________________________________________________________
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] perl_clone takes 5 and more seconds to complete
Posted by Elizabeth Mattijsen <li...@dijkmat.nl>.
At 11:40 -0800 11/4/03, Stas Bekman wrote:
>The only bright side I can see at the moment is that most people
>won't have 150 modules loaded. But 50 modules will scale bad enough.
Agree. Which is why I think you really will have to know what you're
doing if you want to use mod_perl with a worker mpm.
This may be old news to some, but I wrote an article about this about
two months ago on Perlmonks: Things you need to know before
programming Perl ithreads.
http://www.perlmonks.org/index.pl?node_id=288022
So, in the worker mpm, you need to load as little as possible before
cloning, and only load modules when they are really needed inside the
thread. This is perpendicular to prefork mpm, where you want to load
as much as possible beforehand.
One of my related projects is load.pm (on CPAN) which is an
AutoLoader type module with a twist. It allows for a more flexible
way of loading modules. It allows external control over whether a
module will load subroutines on demand or all subroutines at once.
In a worker mpm you would want on demand loading, for a prefork mpm
you'd want it all at once.
As my plan for world domination, all core modules should use
"load.pm", or the load.pm functionality should somehow become part of
interpreter. I'd appreciate feedback whether this is a good idea, or
just a delusion of grandeur on my part. ;-)
Liz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] perl_clone takes 5 and more seconds to complete
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Tue, 4 Nov 2003, Stas Bekman wrote:
>
>
>>I've noticed earlier that the new ithreads test take ages
>>to run. Because by the time they run the interpreter has
>>about 150 modules loaded, and it takes ages to
>>perl_clone() a new ithread.
>
> [ ... ]
>
>>Randy, do you see the same slow behavior under win32? I
>>expect it to be the case.
>
>
> Yes, I do; sometimes things even time out (after 60 s)
> before starting.
Same here :( Thanks Randy for the confirmation.
__________________________________________________________________
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] perl_clone takes 5 and more seconds to complete
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Tue, 4 Nov 2003, Stas Bekman wrote:
> I've noticed earlier that the new ithreads test take ages
> to run. Because by the time they run the interpreter has
> about 150 modules loaded, and it takes ages to
> perl_clone() a new ithread.
[ ... ]
> Randy, do you see the same slow behavior under win32? I
> expect it to be the case.
Yes, I do; sometimes things even time out (after 60 s)
before starting.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org