On Wed, 18 Sep 2002, Peter Bi wrote:
> Problem in authentication: if mod_perl returns cached header and the
> document is proxy cached in the plain Apache, the backend authentication
> handler (in the mod_perl server) will not be able to protect it.
If you use HTTP Basic authentication then res
On Wed, 18 Sep 2002, Peter Bi wrote:
> The linked page is great, especially the first picture.
>
> Problem in authentication: if mod_perl returns cached header and
> the document is proxy cached in the plain Apache, the backend
> authentication handler (in the mod_perl server) will not be able
>
> "PB" == Peter Bi <[EMAIL PROTECTED]> writes:
PB> The linked page is great, especially the first picture.
PB> Problem in authentication: if mod_perl returns cached header and the
PB> document is proxy cached in the plain Apache, the backend authentication
PB> handler (in the mod_perl server
Message -
From: "Ask Bjoern Hansen" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "Josh Chamas" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, September 18, 2002 3:36 AM
Subject: Re: performance regarding mod_perl vs mod_c with embedded perl
&g
On Thu, 12 Sep 2002 [EMAIL PROTECTED] wrote:
> Hi Josh,
>
> How about the "dual setup", a plain Apache + a mod_perl
> Apache, which some mod_perl sites are based on?
You don't do that for "raw performance" as measured in a typical
simple benchmark environment. The dual setup is used to not
need
Hi Josh,
How about the "dual setup", a plain Apache + a mod_perl
Apache, which some mod_perl sites are based on? Another
interesting candidate is fastCGI.
Peter
> We get very similar numbers in our benchmarking. Please see
> the benchmarks I have published on this at:
>
>http://chamas.
Pierre Laplante wrote:
> I do not use mod_perl with CGI emulation.
Actually PerlSetupEnv is on by default. Put PerlSetupEnv Off in your
httpd.conf.
> Here is my mod_perl code:
You are not running the same Perl code in both situations. Under
mod_perl, you are using Apache::File and various m
Pierre Laplante wrote:
> If I compiled a c module that embed a perl interpreter and
> I benchmark this again the same module in mod_perl
>
> I got a big difference in favor of mod_c.
>
.5 ms per request is not a big difference. It seems
that way when you are a benchmarking a trivial applicatio
On Wed, 11 Sep 2002, Perrin Harkins wrote:
> Pierre Laplante wrote:
> > If I compiled a c module that embed a perl interpreter and
> > I benchmark this again the same module in mod_perl
> >
> > I got a big difference in favor of mod_c.
>
> It will be hard for anyone to give you a good answer un
Pierre Laplante wrote:
> If I compiled a c module that embed a perl interpreter and
> I benchmark this again the same module in mod_perl
>
> I got a big difference in favor of mod_c.
It will be hard for anyone to give you a good answer unless you post the
code that you benchmarked. At a guess,
Interesting but isn't the difference within
statistical "fluctuation" ? :-)
Did you compare them to the pure C module (without embed
Perl)?
Peter Bi
> If I compiled a c module that embed a perl interpreter and
> I benchmark this again the same module in mod_perl
>
> I got a big difference i
If I compiled a c module that embed a perl interpreter and
I benchmark this again the same module in mod_perl
I got a big difference in favor of mod_c.
For example mod_c give with ab:
Requests per second:674.76 [#/sec] (mean)
Time per request: 11.86 [ms] (mean)
Time per request:
12 matches
Mail list logo
