You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Mike Blazer <bl...@peterlink.ru> on 2002/07/08 16:39:04 UTC
sections
Hi All,
I'm developing a multi-httpd configuration with the http accelerating
proxy, well practically the same that was described in the Apache
mod_perl guide. 2 httpd+mod_perl - one for very fast process with low
need in modules, and the other one for statistics, near 1MB of modules,
much slower in comparence with the 1st one. And the 3rd -
httpd+mod_proxy (or may be mod_accel by Igor Sysoev that I've read about
only yesterday :)
Right now this all happens on one and the same machine with one
ip-address. So, I've got the idea to attach busy mod_perl httpds to some
unusual ports on 127.0.0.1 and make them available from localhost only.
While proxy is supposed to handle 7+ name based virtual hosts (the
number is DB-dependent)
OK, this goes OK so far (cross fingers). Before this poin it worked very
nice on one httpd with the large <Perl> section that includes DB call to
find out which virtual hosts to initiate. But now with this
httpd+mod_proxy I can't use <Perl> section because it shouldn't use
mod_perl, right? It's supposed to be lightweight.
Well, the question is, what if I'll load mod_perl only for <Perl>
section parsing and generating the dynamic config with
Apache->httpd_conf method, and no real mod_perl locations - would this
still make server childs much bigger then without mod_perl?
Sorry, as I'm mainly on Win32 and the production server is now built
statically, I'm a little limited in experiments loading modules. I'd
like to know also would the child-servers size depend on static/DSO
installation of the proxy-httpd with mod_perl (again - to run on server
statup only and parse <Perl> sections only). May be DSO httpd will load
mod_perl.so on startup and not copy it to child servers as they don't
need it?
Or may be there is some way to un-load mod_perl after <Perl> sections
processing?
Thanks, any input is much appreciated
--
==================================
Mike Blazer
blazer@peterlink.ru
==================================
Re: sections
Posted by "Randal L. Schwartz" <me...@stonehenge.com>.
>>>>> "Randal" == Randal L Schwartz <me...@stonehenge.com> writes:
Randal> using Template Toolkit. Easy'nuff. Lots of common stuff, plus unique
Randal> stuff. You can use "tpage" and then there's not even any programming:
Randal> httpd.conf.pages: httpd.conf.tmpl
Randal> tpage --define server=pages < $< > $@
Randal> httpd.conf.proxy: httpd.conf.tmpl
Randal> tpage --define server=proxy < $< > $@
Randal> then check [% IF server = 'pages'; ... ; END %] in your templates.
Or duh, even simpler:
[%
FOREACH server = ['pages', 'proxy'];
FILTER redirect("httpd.conf.$server");
-%]
... everything else ...
[%
END; # filter redirect
END; # foreach
-%]
Then just "tpage" the file, and you've got a new version!
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: sections
Posted by Mike Blazer <bl...@peterlink.ru>.
"Randal L. Schwartz" wrote:
>
> >>>>> "Mike" == Mike Blazer <bl...@peterlink.ru> writes:
>
> Mike> Yeah, thanks. But the whole that site has nothing to do without the
> Mike> database :) It almost has no static content.
> Mike> But seems like you are both right. Template would be really safer. While
> Mike> this also breaks the nice concept of starting each server with apachectl
> Mike> -D <name> and having all confugurables (perl vars, hashes) together in
> Mike> the same file.
>
> Solution:
>
> generate
>
> httpd.conf.pages
> httpd.conf.proxy
>
> using Template Toolkit. Easy'nuff. Lots of common stuff, plus unique
> stuff. You can use "tpage" and then there's not even any programming:
>
> httpd.conf.pages: httpd.conf.tmpl
> tpage --define server=pages < $< > $@
> httpd.conf.proxy: httpd.conf.tmpl
> tpage --define server=proxy < $< > $@
>
> then check [% IF server = 'pages'; ... ; END %] in your templates.
>
> Make httpd.conf be simply:
>
> <ifdefine pages>
> Include httpd.conf.pages
> </ifdefine>
> <ifdefine proxy>
> Include httpd.conf.proxy
> </ifdefine>
> <ifdefine !pages>
> <ifdefine !proxy>
> Include httpd.conf.other
> </ifdefine>
> </ifdefine>
>
> Done. :)
Well, thanks, this is much what I'm doing
<IfDefine be-image>
PidFile logs/httpd_image.pid
ScoreBoardFile logs/apache_runtime_status.image
<Perl>
$Counter::INI::httpd_name = "image";
</Perl>
</IfDefine>
<IfDefine be-pages>
PidFile logs/httpd_pages.pid
ScoreBoardFile logs/apache_runtime_status.pages
<Perl>
$Counter::INI::httpd_name = "pages";
</Perl>
</IfDefine>
<Perl>
$Counter::INI::ssl = 0;
</Perl>
<IfDefine SSL>
<Perl>
$Counter::INI::ssl = 1;
</Perl>
</IfDefine>
etc.
but then the virtual hosts vary so much that it's no use to use a
template - they are very different. Plus, my conf work also on my home
Win32 machine, so all paths are also calculated in <Perl> section. Plus
2 httpd+mod_perl servers (light and heavy) use different subsets of
modules (loaded in different startup.pl files). So, it'd anyway take to
generate a large parts of conf-code and send to template. I'm just
sending it directly to Apache->httpd_conf :)
But as for the proxy (without mod_perl) - yes, I'm already typing a
template, unfortunatelly it seems like the only way...
Anyway, for some future, may be it worth to use some efforts to be able
to use <Perl> sections even for the servers that don't need mod_perl
processing - by loading and unloading mod_perl or by loading it into
some separate thread and killing it after the server startup. It'd be
great to have this feature to configure Apache.
Thanks, I'll look into the templating thing. I'm a little stuck in my
mind in <Perl> sections, because it was already done this way in my
previous 1-server conf. Probably it's better to generate static
conf-files with small <Perl> parts with PerlSetVar's only.
I'll look into that, thanks.
--
==================================
Mike Blazer
blazer@peterlink.ru
==================================
Re: sections
Posted by "Randal L. Schwartz" <me...@stonehenge.com>.
>>>>> "Mike" == Mike Blazer <bl...@peterlink.ru> writes:
Mike> Yeah, thanks. But the whole that site has nothing to do without the
Mike> database :) It almost has no static content.
Mike> But seems like you are both right. Template would be really safer. While
Mike> this also breaks the nice concept of starting each server with apachectl
Mike> -D <name> and having all confugurables (perl vars, hashes) together in
Mike> the same file.
Solution:
generate
httpd.conf.pages
httpd.conf.proxy
using Template Toolkit. Easy'nuff. Lots of common stuff, plus unique
stuff. You can use "tpage" and then there's not even any programming:
httpd.conf.pages: httpd.conf.tmpl
tpage --define server=pages < $< > $@
httpd.conf.proxy: httpd.conf.tmpl
tpage --define server=proxy < $< > $@
then check [% IF server = 'pages'; ... ; END %] in your templates.
Make httpd.conf be simply:
<ifdefine pages>
Include httpd.conf.pages
</ifdefine>
<ifdefine proxy>
Include httpd.conf.proxy
</ifdefine>
<ifdefine !pages>
<ifdefine !proxy>
Include httpd.conf.other
</ifdefine>
</ifdefine>
Done. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: sections
Posted by Mike Blazer <bl...@peterlink.ru>.
Perrin Harkins wrote:
>
> Mike Blazer wrote:
> >>MB> Or may be there is some way to un-load mod_perl after <Perl> sections
> >>MB> processing?
> >>
> >>If you need <Perl> sections only to do initial web server
> >>configuration and you do not need mod_perl features in runtime then
> >>instead of using <Perl> just write Perl script to generate Apache
> >>config file from templates and run it before starting Apache. This way
> >>you do not need mod_perl on frontend Apache at all.
> >
> > Yes, sure, that was my backup idea :) But I just wanted to make all 3
> > configs in one big file, because of tons of the parameters (like log
> > names, leves, auth, ssl etc). To keep it all together and start with -D
> > proxy or -D pages.
>
> Well of course you can do exactly that with what Ilya suggested: one
> template file that your script uses to generate appropriate conf files
> for each server. It's really your only choice for a proxy server. It's
> also somewhat safer, since it means your database doesn't have to be up
> just to start your proxy server.
Yeah, thanks. But the whole that site has nothing to do without the
database :) It almost has no static content.
But seems like you are both right. Template would be really safer. While
this also breaks the nice concept of starting each server with apachectl
-D <name> and having all confugurables (perl vars, hashes) together in
the same file.
--
==================================
Mike Blazer
blazer@peterlink.ru
==================================
Re: sections
Posted by Perrin Harkins <pe...@elem.com>.
Mike Blazer wrote:
>>MB> Or may be there is some way to un-load mod_perl after <Perl> sections
>>MB> processing?
>>
>>If you need <Perl> sections only to do initial web server
>>configuration and you do not need mod_perl features in runtime then
>>instead of using <Perl> just write Perl script to generate Apache
>>config file from templates and run it before starting Apache. This way
>>you do not need mod_perl on frontend Apache at all.
>
> Yes, sure, that was my backup idea :) But I just wanted to make all 3
> configs in one big file, because of tons of the parameters (like log
> names, leves, auth, ssl etc). To keep it all together and start with -D
> proxy or -D pages.
Well of course you can do exactly that with what Ilya suggested: one
template file that your script uses to generate appropriate conf files
for each server. It's really your only choice for a proxy server. It's
also somewhat safer, since it means your database doesn't have to be up
just to start your proxy server.
- Perrin
Re: sections
Posted by Mike Blazer <bl...@peterlink.ru>.
> MB> Or may be there is some way to un-load mod_perl after <Perl> sections
> MB> processing?
>
> If you need <Perl> sections only to do initial web server
> configuration and you do not need mod_perl features in runtime then
> instead of using <Perl> just write Perl script to generate Apache
> config file from templates and run it before starting Apache. This way
> you do not need mod_perl on frontend Apache at all.
Yes, sure, that was my backup idea :) But I just wanted to make all 3
configs in one big file, because of tons of the parameters (like log
names, leves, auth, ssl etc). To keep it all together and start with -D
proxy or -D pages.
Thanks, but this would stay for the last chance :)
--
==================================
Mike Blazer
blazer@peterlink.ru
==================================
Re: sections
Posted by Ilya Martynov <il...@martynov.org>.
>>>>> On Mon, 08 Jul 2002 18:39:04 +0400, Mike Blazer <bl...@peterlink.ru> said:
MB> Hi All,
MB> [..snip..]
MB> Well, the question is, what if I'll load mod_perl only for <Perl>
MB> section parsing and generating the dynamic config with
MB> Apache-> httpd_conf method, and no real mod_perl locations - would this
MB> still make server childs much bigger then without mod_perl?
Yes, it will.
MB> [..snip..]
MB> Or may be there is some way to un-load mod_perl after <Perl> sections
MB> processing?
If you need <Perl> sections only to do initial web server
configuration and you do not need mod_perl features in runtime then
instead of using <Perl> just write Perl script to generate Apache
config file from templates and run it before starting Apache. This way
you do not need mod_perl on frontend Apache at all.
--
Ilya Martynov (http://martynov.org/)