How to test if I got Mod_Perl in apache?

[@]

Is there any way to tell if mod_perl is installed in apache? I am using a
shared account. No root access.

 

[Gregory Toomey]

Is there any way to tell if mod_perl is installed in apache? I am using a
shared account. No root access.

You probably can't if if have a shared account. As root, you need to type
type 'httpd -l ' and look for mode_perl.

And you will need to modify httpd.conf, which you probably cant do either.

Try a cheap VPS at www.linode.com or similar.

gtoomey

 

[@]

Is there any way to tell if mod_perl is installed in apache? I am using
a

You probably can't if if have a shared account. As root, you need to type
type 'httpd -l ' and look for mode_perl.

And you will need to modify httpd.conf, which you probably cant do either.

Try a cheap VPS at www.linode.com or similar.

gtoomey

However, PHP is included in the HTTP header. I thought if Mod_perl is
included, it should say something.

Another idea. Is there a program which will have different results in
mod_perl or none. Then I can test it with this script.

 

[Gregory Toomey]

However, PHP is included in the HTTP header. I thought if Mod_perl is
included, it should say something.

Another idea. Is there a program which will have different results in
mod_perl or none. Then I can test it with this script.

If Apache does not say 'mod_perl' in the headers it is unlikely to be
installed.

You really need root access to configure mod_perl.

gtoomey

 

[@]

If Apache does not say 'mod_perl' in the headers it is unlikely to be
installed.

You really need root access to configure mod_perl.

gtoomey

I agree. That is one server shows it
2004-10-03 03:41:30.401 Server: Apache/1.3.28 (Unix) PHP/4.3.3 mod_perl/1.28
mod_ssl/2.8.15 OpenSSL/0.9.7c
Another does not:
2004-10-03 03:42:59.700 Server: Apache/1.3.31 (Unix) mod_gzip/1.3.26.1a
mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 PHP/4.3.8
FrontPage/5.0.2.2634a mod_ssl/2.8.19 OpenSSL/0.9.7a
Here is mine:
2004-10-03 03:44:17.782 Server: Apache/1.3.29 (Unix)
However, mine does have PHP, so it is very possible that the Apache is set
up not to say anything about those added headers.

So I am still looking for a script to test it.

 

[Sherm Pendley]

I agree.

Gregory was not giving you an opinion, he was informing you of a fact.
Good of you to agree with the facts though.

Here is mine:
2004-10-03 03:44:17.782 Server: Apache/1.3.29 (Unix)

Your server does not have mod_perl installed. See how easy that was?

However, mine does have PHP, so it is very possible that the Apache is set
up not to say anything about those added headers.

Possible? Sure, anything's possible - including little green men on
Mars. But I won't bet on that, or on your server having mod_perl and not
reporting it.

So I am still looking for a script to test it.

Why? Just ask your hosting provider, and they'll tell you that you don't
have it.

So what's got your panties in a bunch over mod_perl? Between this series
of posts, and the other ones in the "PHP vs. Perl" thread, I highly
doubt you'll be able to make effective use of it anyway.

It's not a simple matter of just sprinkling your site with some sort of
"magic mod_perl dust" and making it go faster - for any chance at *real*
improvement, you have to write your scripts with mod_perl in mind, and
optimize them to take advantage of the persistent environment.

sherm--

 

[@]

Here is mine:

Your server does not have mod_perl installed. See how easy that was?


Possible? Sure, anything's possible - including little green men on
Mars. But I won't bet on that, or on your server having mod_perl and not
reporting it.

If it has PHP but not report it, then it is possible for mod_perl too.
In fact, openssl is working but not reported too.

I just want to know if my perl cgi is faster than PHP is because I got
mod_perl or the fact is PHP is still too much slower than Perl regardless of
apache settings.

 

[Sherm Pendley]

I just want to know if my perl cgi is faster than PHP is because I got
mod_perl

It's not. As I said, you need to be aware of mod_perl and write your
code specifically to take advantage of it to see any significant
performance boost.

So even if you *did* have mod_perl on your server - and I'm certain that
you don't - you wouldn't be getting any performance gains from it,
because you haven't optimized your Perl code for it.

sherm--

 

[Gunnar Hjalmarsson]

So even if you *did* have mod_perl on your server - and I'm certain
that you don't - you wouldn't be getting any performance gains from
it, because you haven't optimized your Perl code for it.

Quote from http://perl.apache.org/start/tips/registry.html :

"Existing CGI scripts will run much faster under mod_perl."

 

[Gunnar Hjalmarsson]

Is there any way to tell if mod_perl is installed in apache? I am
using a shared account. No root access.

You can check whether $ENV{MOD_PERL} is set. If it is, your script is
running under mod_perl, if not, mod_perl is not enabled for your
account whether it happens to be installed or not.

 

[Juha Laiho]

Is there any way to tell if mod_perl is installed in apache? I am using a
shared account. No root access.

You might write a perl-based page where you print a value from the
Apache::Constants package -- that should only be available for
mod_perl environments. Also Apache::Status package might be one you
could use for testing.

And then the easy way: ask your hosting provider.
(answer of "don't know" means you need to change providers)

 

[Juha Laiho]

2004-10-03 03:44:17.782 Server: Apache/1.3.29 (Unix)
However, mine does have PHP, so it is very possible that the Apache is set
up not to say anything about those added headers.

This output can be achieved with 'ServerTokens OS' in the Apache httpd.conf.
So, no great magic needed - and it's rather common to set up Apache this
way to reduce the amount of information it provides for potential attackers.

 

[Sherm Pendley]

Quote from http://perl.apache.org/start/tips/registry.html :

"Existing CGI scripts will run much faster under mod_perl."

That has not been my experience - and I've done a *lot* of mod_perl, for
sites that get more traffic than slashdot.

On the other hand, the scripts I've worked with have been as small and
tight as I could make them to begin with. They didn't benefit all that
much by simply dropping them into Apache::Registry, since the compiler
overhead for those scripts wasn't all that much to begin with.

I can see where the difference would be much more dramatic though, if
you're dealing with a 10kloc behemoth that spends as much or more time
compiling than it does running. ;-)

sherm--

 

[Gunnar Hjalmarsson]

That has not been my experience - and I've done a *lot* of
mod_perl, for sites that get more traffic than slashdot.

Thanks for sharing; I have never really understood what's the magic
that would make that statement true.

On the other hand, the scripts I've worked with have been as small
and tight as I could make them to begin with. They didn't benefit
all that much by simply dropping them into Apache::Registry, since
the compiler overhead for those scripts wasn't all that much to
begin with.

I can see where the difference would be much more dramatic though,
if you're dealing with a 10kloc behemoth that spends as much or
more time compiling than it does running. ;-)

Such as loading POSIX for a simple date formating, or CGI for a simple
query-string parsing...

 

[Gunnar Hjalmarsson]

I just benched the smallest and tightest script I could come up
with:

#!/usr/bin/perl

print "Content-Type: text/html\r\n\r\n";
print "<html>Hello World!</html>";

{grin}

A vanilla CGI run of 3000 (using ab -n 3000) gave me 175.36
requests per second. Moving that over to mod_perl and
Apache::Registry gave me 298.15. I'd call that a significant
difference.

OTOH, no human will ever be able to notice the difference.

 

[Sherm Pendley]

I'd be interested in hearing more about your typical configuration. Do
you use fastcgi or Pperl? I believe that statement assumes a typical CGI
environment rather than a persistent one.

Neither - I'm comparing the performance of vanilla CGIs to the
performance of those same scripts running, unmodified, under
Apache::Registry.

I just benched the smallest and tightest script I could come up with:

#!/usr/bin/perl

print "Content-Type: text/html\r\n\r\n";
print "<html>Hello World!</html>";

Heh... Okay, maybe I should rephrase that part. How about, I reduced
each of the CGI scripts as small and tight as I could get them, while
still functioning as they needed to. ;-)

As you add code to this example, the execution time will tend to rise at
a faster rate than the compilation time - that is, the compilation time
becomes less of a factor in overall performance.

But the compilation time keeps rising with code size, while execution
time generally doesn't - the 10kloc script I mentioned doesn't generally
exercise every code path for every invocation. It's on the other side of
the curve, with compilation time once again playing an increasingly
important role.

There is a "sweet spot" where execution time is the major determining
factor, with compilation accounting for a relatively insignificant part
of the total time spent. Factoring CGI code out into multiple scripts so
that traffic is well balanced among the scripts, and each one can hit
this "sweet spot", can be a big win - but unfortunately hitting that
spot can sometimes require candles, a bottle of rum, and a chicken.

Hitting that spot also can work to minimize the "automatic" improvement
you get by moving to Apache::Registry. Using it essentially reduces the
compilation time to zero. That's certainly an improvement - but how much
of an improvement will depend on how big an impact the compilation time
had on performance to begin with. If that wasn't the major bottleneck,
then simply dropping a CGI into a Registry directory won't help much.

sherm--

 

[Gunnar Hjalmarsson]

There's an implied "when rewritten to be compatible with
Apache::Registry or as a proper handler" missing from that
sentence.

That's not how I interpret the information at perl.apache.org. Take
for instance the introductory para at http://perl.apache.org/start/ :

"Accelerate your existing dynamic content

The standard Apache::Registry module can provide 100x speedups for
your existing CGI scripts and reduce the load on your server at the
same time. A few changes to the web server's config is all that is
required to run your existing CGI scripts at lightning speed."

Their claim appears pretty clear to me.

 

[@]

This is a tip I have, but I don't use mod_perl so it's just "as is".

#!/usr/bin/perl
print "Content-type: text/html\n\n";
while (($key,$value) = each %ENV) {
print "$key=$value<br>";
}

# look for the line saying "Gateway Interface". If it says "CGI/1.1"
# then you are using the standard apache-perl interface, but if it says
#"CGI-Perl/1.1" then you are running it through mod_perl

This is mine:
GATEWAY_INTERFACE=CGI/1.1

So it proves even more than PHP is much slower than Perl, because my
benchmark shows Perl is faster and I don't have mod_perl. hey hey.