mod_perl2 & POST data

Hello all,

I'm currently researching switching alot of my company's code to using
mod_perl (mod_perl2 specifically as the title implies, but some "odd"
version that redhat enterprise ships with). Right now I am stuck on
the best way to parse out POST data. I am using $r->args for GETS, and
right now using Apache::compat and $r->content for POSTS as I can't
find any info on other ways to do it currently.

My question is are there other suggestions on how to do this and which
ways of getting the data are the fastest/most effecient (we are highly
concerned with the code speed and mem/proc usage on the servers). We
are shying away from CGI.pm at the moment as it seems to be a bit of a
hog, but if there is some use of it I am missing for these types of
things I would love to hear about them.

Thanks,
Brian

Re: mod_perl2 & POST data

neophenix@gmail.com schrieb:
> We are shying away from CGI.pm at the moment as it seems to be a bit of a
> hog.

I'd give CGI.pm a try. Internally it detects if mod_perl is used and
uses mod_perl to fetch the data, so it shouldn't be that much CPU
overhead. Although it may be a memory overhead. But I think it's worth a
try.

-Thomas

Re: mod_perl2 & POST data

"neophenix@gmail.com" wrote:
> Hello all,
>
> I'm currently researching switching alot of my company's code to using
> mod_perl (mod_perl2 specifically as the title implies, but some "odd"
> version that redhat enterprise ships with). Right now I am stuck on
> the best way to parse out POST data. I am using $r->args for GETS, and
> right now using Apache::compat and $r->content for POSTS as I can't
> find any info on other ways to do it currently.

Do you need to be able handle multipart posts, or just the old fashioned
single-part ones? I seem to remember something that could handle single-
part posts, but I'll have to go digging to find it again.

> My question is are there other suggestions on how to do this and which
> ways of getting the data are the fastest/most effecient (we are highly
> concerned with the code speed and mem/proc usage on the servers). We
> are shying away from CGI.pm at the moment as it seems to be a bit of a
> hog,

Are you relying on heresay and/or irrelevant tests, or have you tested it
under your conditions (mod_perl2) and found it to be a hog? If so, can
you describe your tests?

I used ab2 -n 1000 -c 4 to do some benchmarking either with no query or
with a simple "?foo=bar" query, and under regular cgi-bin using CGI.pm
slowed things down a lot (compared to simply printing hello world and
ignoring the query altogether), 8.9 ms per request versus 41.3 ms.

But under mod_perl (not mod_perl2), the different between using CGI.pm to
parse the query and not using it at all was undetectable, 5 to 7 ms per
request either way.

(single CPU server, ab2 client was on same LAN as server)

Xho

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB

Re: mod_perl2 & POST data

xhoster@gmail.com wrote:
>
> Do you need to be able handle multipart posts, or just the old fashioned
> single-part ones? I seem to remember something that could handle single-
> part posts, but I'll have to go digging to find it again.

This would just be for single-part posts.

>
> Are you relying on heresay and/or irrelevant tests, or have you tested it
> under your conditions (mod_perl2) and found it to be a hog? If so, can
> you describe your tests?

To be honest I am just going by what I was told by others here and what
they have seen under normal cgi-bin use. The main issue is, if we are
only loading up 1 use of these scripts on each server and as such only
loading up CGI.pm once, then that is fine. However we need to load up,
say 400 copies of our index file on each machine, and each one would
then need CGI. We were told, and have read that each uri loads up the
packages it needs into memory, so I was led to believe that loading up
some 400 instances of a module like CGI would be a bit much.

I could be wrong of course and what we were told could be inaccurate.
I am really just starting looking in to all this and only have the
Practical mod_perl and mod_perl developer's cookbook to look through
which are both mod_perl1 sadly.

Re: mod_perl2 & POST data

> I used ab2 -n 1000 -c 4 to do some benchmarking either with no query or
> with a simple "?foo=bar" query, and under regular cgi-bin using CGI.pm
> slowed things down a lot (compared to simply printing hello world and
> ignoring the query altogether), 8.9 ms per request versus 41.3 ms.
>
> But under mod_perl (not mod_perl2), the different between using CGI.pm to
> parse the query and not using it at all was undetectable, 5 to 7 ms per
> request either way.

Apologize for the double post, but forgot to respond to this. I have
been using ab2 to get some benchmark numbers and yes I do get the same
results as you in that the use of CGI and not is negligable. We know
how to make the scripts fast on their own, now we are worried about
memory usage when we load them all up.

Re: mod_perl2 & POST data

"neophenix@gmail.com" wrote:
> xhoster@gmail.com wrote:
> >
> > Do you need to be able handle multipart posts, or just the old
> > fashioned single-part ones? I seem to remember something that could
> > handle single- part posts, but I'll have to go digging to find it
> > again.
>
> This would just be for single-part posts.

It turns out that what I was thinking of us was just a way to run
cgi-like scripts without a web server. The perl script itself acts like
a web server, but it still uses CGI.pm to do the request parsing (but
doing it that way only doesn't work with multi-part post, so that part
of my memory was correct.)

>
> >
> > Are you relying on heresay and/or irrelevant tests, or have you tested
> > it under your conditions (mod_perl2) and found it to be a hog? If so,
> > can you describe your tests?
>
> To be honest I am just going by what I was told by others here and what
> they have seen under normal cgi-bin use. The main issue is, if we are
> only loading up 1 use of these scripts on each server and as such only
> loading up CGI.pm once, then that is fine. However we need to load up,
> say 400 copies of our index file on each machine, and each one would
> then need CGI.

You kind of lost me about loading up index files. But anyway, if one uses
the normal mod_perl (Apache::Registry) method and use it with 500 scripts,
they all share the same image of CGI.pm---they are not loading it 500
times. I would be very surprised if the "normal" method of using mod_perl2
(ModPerl::Registry, I think) was any different in that regard.

> We were told, and have read that each uri loads up the
> packages it needs into memory, so I was led to believe that loading up
> some 400 instances of a module like CGI would be a bit much.

With FastCGI and such that may be the case, but with Registry it should not
be. More of an issue would be having the non-CGI.pm portion of all those
scripts in memory. You should extract as much code that is in common
between them into your own custom *.pm, that way *that* code can be shared
amongst all of them, too.

Xho

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB

Re: mod_perl2 & POST data

> You kind of lost me about loading up index files. But anyway, if one uses
> the normal mod_perl (Apache::Registry) method and use it with 500 scripts,
> they all share the same image of CGI.pm---they are not loading it 500
> times. I would be very surprised if the "normal" method of using mod_perl2
> (ModPerl::Registry, I think) was any different in that regard.
>
> > We were told, and have read that each uri loads up the
> > packages it needs into memory, so I was led to believe that loading up
> > some 400 instances of a module like CGI would be a bit much.
>
> With FastCGI and such that may be the case, but with Registry it should not
> be. More of an issue would be having the non-CGI.pm portion of all those
> scripts in memory. You should extract as much code that is in common
> between them into your own custom *.pm, that way *that* code can be shared
> amongst all of them, too.

That is excellent if that is indeed the case then. Actually 99% of our
code is in custom modules, the index files really just use them after
some minor "preprocessing" of the data.

It is very possible that we were either told wrong or someone
misunderstood. I will need to look into this more now. If they do all
share modules, then CGI is the way we will more than likely go.

Thanks for the reponses!