You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Larry Leszczynski <la...@emailplus.org> on 2004/09/23 17:53:13 UTC
Threaded MPM and performance (was: Re: Variables in memory.)
Hi all -
> You use interpreter pool size control directives:
> http://perl.apache.org/docs/2.0/user/config/config.html#Threads_Mode_Specific_Directives
>
>
> You don't need to prevent anything. It's just that if your server uses
> very little modperl and mostly doing static requests, you can have
> just a few perl interpreters around (in the threaded mpm) and many
> more threads. The above link explains how to set a limit on the size
> of the pool.
The above link mentions the memory benefits of having few perl intepreters
among many threads e.g. if you have a mix of static and dynamic content.
But it made me wonder what is the effect regarding the "spoonfeeding slow
clients" scenario? In mp1-land I'd run a lightweight reverse proxy to
send dynamic requests back to a heavy mod_perl server, where the heavy
mod_perl process is freed up as soon as content is generated and the
lightweight reverse proxy process feeds the data to a slow client. What
happens in the same situation when running mp2 threaded MPM? Is there any
penalty because the thread which has loaded the perl intepreter stays busy
until all data is returned to the client, as compared to a thread which
has not loaded an interpreter? Is the interpreter which has been loaded
tied up until all the data is returned to the client, or is it freed as
soon as content is generated?
TIA,
Larry
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Threaded MPM and performance
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
> [...]
>
>
>>It depends on many things. For example it's possible to have a simple filter
>>written in C, which will accept all the data from the response handler
>>and then spoonfeed the client, just like the proxy does.
>
>
> Stas, related question: I was looking over the interpreter-pool stuff in
> modperl_interp.c and modperl_callback.c and it looks to me like each call
> to modperl_callback_run_handlers grabs its own interpreter to use. Do
> you know if it's possible, within a single http request, for an auth
> handler and a response handler to use two different perl interpreters?
> It looks to me like it is possible.
Yes. This is controlled by the PerlInterpScope directive:
http://perl.apache.org/docs/2.0/user/config/config.html#C_PerlInterpScope_
if you set it to 'handler' than each phase will have a different
interpreter selected. The default is 'request' so once an interpreter is
selected, it'll be used by all request handlers in the current request.
--
__________________________________________________________________
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Threaded MPM and performance
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
[...]
> It depends on many things. For example it's possible to have a simple filter
> written in C, which will accept all the data from the response handler
> and then spoonfeed the client, just like the proxy does.
Stas, related question: I was looking over the interpreter-pool stuff in
modperl_interp.c and modperl_callback.c and it looks to me like each call
to modperl_callback_run_handlers grabs its own interpreter to use. Do
you know if it's possible, within a single http request, for an auth
handler and a response handler to use two different perl interpreters?
It looks to me like it is possible.
--
Joe Schaefer
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Threaded MPM and performance
Posted by Stas Bekman <st...@stason.org>.
Larry Leszczynski wrote:
> Hi all -
>
>
>>You use interpreter pool size control directives:
>>http://perl.apache.org/docs/2.0/user/config/config.html#Threads_Mode_Specific_Directives
>>
>>
>>You don't need to prevent anything. It's just that if your server uses
>>very little modperl and mostly doing static requests, you can have
>>just a few perl interpreters around (in the threaded mpm) and many
>>more threads. The above link explains how to set a limit on the size
>>of the pool.
>
>
> The above link mentions the memory benefits of having few perl intepreters
> among many threads e.g. if you have a mix of static and dynamic content.
> But it made me wonder what is the effect regarding the "spoonfeeding slow
> clients" scenario? In mp1-land I'd run a lightweight reverse proxy to
> send dynamic requests back to a heavy mod_perl server, where the heavy
> mod_perl process is freed up as soon as content is generated and the
> lightweight reverse proxy process feeds the data to a slow client. What
> happens in the same situation when running mp2 threaded MPM? Is there any
> penalty because the thread which has loaded the perl intepreter stays busy
> until all data is returned to the client, as compared to a thread which
> has not loaded an interpreter? Is the interpreter which has been loaded
> tied up until all the data is returned to the client, or is it freed as
> soon as content is generated?
It depends on many things. For example it's possible to have a simple
filter written in C, which will accept all the data from the response
handler and then spoonfeed the client, just like the proxy does. Or you
could have the proxy just as before. There is no definitive answer here.
Each setup may have it in a different way.
--
__________________________________________________________________
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Threaded MPM and performance (was: Re: Variables in memory.)
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Larry Leszczynski <la...@emailplus.org> writes:
[...]
> The above link mentions the memory benefits of having few perl intepreters
> among many threads e.g. if you have a mix of static and dynamic content.
> But it made me wonder what is the effect regarding the "spoonfeeding slow
> clients" scenario?
I've been trying to get httpd to include a patch for the worker mpm
that will handle this nicely:
http://marc.theaimsgroup.com/?t=109346431300004&r=1&w=2
http://marc.theaimsgroup.com/?t=109587883600002&r=1&w=2
It's not quite ready for a production environment, but it'd
really help if someone with a good "slow-client" test environment
benchmarked it to see if it helps.
--
Joe Schaefer
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html