MESSAGE
| DATE | 2020-12-23 |
| FROM | From: =?UTF-8?Q?Andr=c3=a9_Warnier_=28tomcat/perl=29?=
|
| SUBJECT | Re: [Hangout - NYLXS] Confused about two development utils
|
On 22.12.2020 14:20, Matthias Peng wrote:
> Can I guess mod_perl is the upgraded version of apreq? Thanks Andre.
Not really. They are really 2 different things.
The essence of mod_perl, is to embed a perl interpreter in Apache httpd.
This costs memory, and all the more since many perl modules are not thread-safe, so if you
use them in your code, at this moment the only safe way to do it is to use the Apache
httpd prefork model. This means that each Apache httpd child process has its own copy of
the perl interpreter, which means that the memory used by this embedded perl interpreter
has to be counted n times (as many times as there are Apache httpd child processes running
at any one time).
This can be significant, but it is also relative : if you compare the memory used in the
practice by an Apache httpd with mod_perl and compare it to other possible solutions for
web applications (e.g. a java-based webserver, or back-end solutions running their own
interpreter), you will see that this "bad side of mod_perl" is really not as bad as many
perl and mod_perl detractors would want you to believe.
There are no miracles : if you want to do many complex things in parallel and do them
fast, you are going to use memory and CPU time, no matter which techniques or tools you use.
Once you have admitted the above, having a perl interpreter embedded in Apache httpd
through mod_perl leads to 2 major things :
1) anything written in perl and used by your web application can run *much* faster (with
the right setup), because it will be pre-compiled by the perl interpreter the first time
it is run, and then cached in some intermediate form, which will run say 100 times faster
any subsequent time it is run after that (as long as it runs within the same Apache
child). So, * if you know perl and like perl as a programming language, and you are - as I
am - amazed by the incredible scope and quality and documentation of the perl CPAN library
*, just that makes it worth having a good look at mod_perl.
But this is only one aspect of mod_perl.
2) the most important aspect (in my view), is that mod_perl allows you to really intervene
and "do things", in perl, inside the logic of Apache httpd itself, at just about any step
of the processing of a HTTP request by Apache. Not everyone is interested in doing this,
but if you find that your applications could benefit from being able to inspect and/or
modify the way in which Apache httpd is processing HTTP requests, there is not really any
tool that compares to mod_perl in that respect.
In fact, what mod_perl really allows you to do, is to turn things around : instead of
being this little perl toolbox that is added to httpd, it allows you to use Apache httpd -
with all its finely tuned code and extensions - *as a toolbox* to do what you want in your
perl application. That is the real power of mod_perl. If mod_perl did not exist, the only
real alternative for doing that kind of thing, would be to write your own Apache add-on
modules in C. (Which would mean "forget about CPAN" and start looking elsewhere for
anything you need in addition).
In comparison to mod_perl, the apreq library is more limited and more focused. It's main
aspect in my view, is to provide a more efficient alternative for the perl CGI module, in
terms of processing cgi-bin script arguments and cookies (and maybe some other things
which I admit I've never really looked at).
I guess that by now you know that I am really a perl and mod_perl fan.
As far as perl is concerned, as a programming language : there are people who like it, and
others who don't, and it is quite pointless to try to convert the ones into the others.
But if what you want is a programming tool which allows you to do many different things
quickly - even things of which you initially know very little about - there is still no
real alternative to the conjunction of perl and the CPAN library.
>
>
> On 22.12.2020 06:49, Matthias Peng wrote:
> > Hello
> >
> > I am developing a simple mp2 application.
> > I looked for the installation for mp2 utils, and found this two:
> >
> > libapache2-mod-perl2
> >
> > libapache2-mod-apreq2
> >
> >
> > what're their relations? Should I install both, or only the first one?
> >
>
> Hi.
>
> They are different and independent packages and module libraries, and you can use the one
> or the other, or both, depending on your needs.
> (We always install both, and we use both)
>
> For mod_perl per se, you need only the /libapache2-mod-perl2/ package.
> This gives you access to all the stuff documented here :
> http://perl.apache.org/docs/2.0/api/index.html
>
>
> *except* what is at the very end of that page :
>
> "Part VI: Related Modules" -> libapreq modules
> (this is what is contained in the separate /libapache2-mod-apreq2/ package)
> The documentation for libapreq is at :
> http://httpd.apache.org/apreq/docs/libapreq2/modules.html
>
>
> It may be a bit confusing at first, because both (independent) packages use some common
> namespaces ("Apache2::" and "APR::"), and because each of mod_perl and libapreq2 have
> their own form of "Apache Request object", named very similarly :
> - for mod_perl it is Apache2::RequestRec
> - for libapreq it is Apache2::Request
> (I guess that libapreq was first, that's why they got the better name ;-)
>
> I am a bit reluctant to try explaining the difference further (for fear of confusing you
> further), but here is a very rough summary :
>
> - to deal with 99% of what has to do with controlling what happens within Apache httpd in
> terms of processing HTTP requests (or just to run your perl scripts faster), use the
> mod_perl package.
> So install /libapache2-mod-perl2/ first, and start coding.
>
> - if you finds out later that you have to do a lot of processing of CGI parameters (the
> request "query string") or cookies, you can then install and use use the libapreq API
> which (among other things) provide an alternative to what the CGI module provides.
>
> In any case, there is a bit of a learning curve, but it is great fun and very powerful.
>
>
>
>
_______________________________________________
Hangout mailing list
Hangout-at-nylxs.com
http://lists.mrbrklyn.com/mailman/listinfo/hangout
|
|
