Re: performance regarding mod_perl vs mod_c with embedded perl
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 response to request with Authorization header will never be cached by mod_proxy or mod_accel. However mod_accel can ignore Authorization header by per location/files basis. Igor Sysoev http://sysoev.ru
Re: performance regarding mod_perl vs mod_c with embedded perl
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) will not be able to protect it. Not true. The authentication info *is* honored with front/back end setup.
Re: performance regarding mod_perl vs mod_c with embedded perl
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 to protect it. Obviously you need to serve the pages from whatever stage that can handle authorization. However, even if it means you can't cache things in the proxy, you will still get great benefits from having the light proxy process waiting for the client to receive the data and serving static image files and such instead of having the expensive mod_perl process doing it. Raw benchmark numbers will come out a bit lower, but you don't care as a proper setup will save you LOTS of memory, database connections and what have you not. http://develooper.com/modperl/performance_tuning.html (Click Next on the top of each slide to progress ... The first few slides looks weird in Mozilla 1.0 on my Linux box but are fine in Chimera on Mac OS X - get a Mac! :-) ) -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: performance regarding mod_perl vs mod_c with embedded perl
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 needlessly waste resources in a real setup. Raw benchmark numbers will come out a bit lower, but you don't care as a proper setup will save you LOTS of memory, database connections and what have you not. http://develooper.com/modperl/performance_tuning.html (Click Next on the top of each slide to progress ... The first few slides looks weird in Mozilla 1.0 on my Linux box but are fine in Chimera on Mac OS X - get a Mac! :-) ) - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: performance regarding mod_perl vs mod_c with embedded perl
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 to protect it. Peter Bi - Original 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 You don't do that for raw performance as measured in a typical simple benchmark environment. The dual setup is used to not needlessly waste resources in a real setup. Raw benchmark numbers will come out a bit lower, but you don't care as a proper setup will save you LOTS of memory, database connections and what have you not. http://develooper.com/modperl/performance_tuning.html (Click Next on the top of each slide to progress ... The first few slides looks weird in Mozilla 1.0 on my Linux box but are fine in Chimera on Mac OS X - get a Mac! :-) ) - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: performance regarding mod_perl vs mod_c with embedded perl
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 methods of the perl version of the request record ($r). In your mod_c version, you do those things in C. That will make a difference. You seem to be using Error.pm to trap errors in the mod_perl version and normal eval/die constructs (called from C) in the mod_c version. Error.pm will slow things down a little. Also, if you are not handling any phases of the request other than the content handler, you can improve the speed of mod_perl by compiling it without the hooks for the other phases. - Perrin
Re: performance regarding mod_perl vs mod_c with embedded perl
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.com/bench/ If you compare the results of the Hellow World 2000 vs. the Hello World for mod_perl and C Apache API module, you will see that the performance gap narrows the more application type work you do. This would not hold up if you were doing intensive number crunching I might add, where C would be much better in the end game, but if you are just doing web applications, you probably won't get much more performance out of a pure C implementation. Note, that if you ever have any critical sections of code in perl that need to be optimized, you can always code up that section in C using XS or the newer Inline:: modules. Further realize that if you pick an application environment like Template Toolkit, Embperl, or AxKit, you are often getting a lot of fast C under the hood anyway as those authors have already done the optimizations for you. Regards, Josh Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com
Re: performance regarding mod_perl vs mod_c with embedded perl
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, I would say that mod_perl is probably doing more work in order to give you access to apache internals. You also may not have configured mod_perl for best performance. For example, if you have it configured to emulate CGI by setting up environment variables that will take more time. - Perrin
Re: performance regarding mod_perl vs mod_c with embedded perl
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 unless you post the
code that you benchmarked. At a guess, I would say that mod_perl is
probably doing more work in order to give you access to apache
internals. You also may not have configured mod_perl for best
performance. For example, if you have it configured to emulate CGI by
setting up environment variables that will take more time.
- Perrin
I do not use mod_perl with CGI emulation.
Here is my mod_perl code:
package Apache::modperl;
require 5.001;
use strict;
use Error qw(:try);
use Apache::Constants qw(:common);
use Apache::File ();
BEGIN {
use constant REVISION = '$Revision: 1.5 $ ';
use constant DEBUG = 0;
use constant BANNIERE = 0;
use constant LIST = 1;
use constant MTIME = 2;
use constant ID = '$Id $ ';
}
sub handler {
my $r = shift;
try {
main($r) ;
}
catch Error::Simple with {
my $e = shift;
my $error = $e - {'-text'};
$r - content_type ('text/html');
$r - send_http_header;
print bError: $error/b\n;
$r - log_error(Erreur d'éxécution de . '$Id: bannieres.pm,v
1.5 2002/09/10 01:15:11 laplante Exp $' . : $error.\n);
};
return OK;
}
sub main {
my($r)=@_;
$r - content_type ('text/html');
$r - send_http_header;
$r - print(HTML\n);
$r - print(HEADER\n);
$r - print(TITLEHello There/TITLE\n);
$r - print(/HEADER\n);
$r - print(BODY\n);
$r - print(H1Hello $ENV{'REMOTE_NAME'}/H1\n);
$r - print(/BODY\n);
$r - print(/HTML\n);
}
Here is my 'C' mode:
#include httpd.h
#include http_config.h
#include http_core.h
#include http_log.h
#include http_protocol.h
#include http_request.h
#include http_main.h
#include util_script.h
#include util_md5.h
#include EXTERN.h
#include perl.h
static PerlInterpreter *my_perl=NULL;
#ifndef DO_CLEAN
#define DO_CLEAN 0
#endif
extern void xs_init();
module MODULE_VAR_EXPORT hello_module;
/* here's the content handler */
static int hello_handler(request_rec *r) {
char *hostname;
char *embedding[] = { , /tmp/persistent.pl };
char *args[] = { /tmp/toto.pl, DO_CLEAN, NULL };
int exitstatus;
STRLEN n_a;
r-content_type = text/html;
ap_send_http_header(r);
hostname = ap_get_remote_host(r-connection, r-per_dir_config,
REMOTE_NAME);
ap_rputs(HTML\n, r);
ap_rputs(HEADER\n, r);
ap_rputs(TITLEHello There V3/TITLE\n, r);
ap_rputs(/HEADER\n, r);
ap_rputs(BODY\n, r);
if (my_perl == NULL) {
ap_rputs(my_perl is null V3\n, r);
if((my_perl = perl_alloc()) == NULL) {
fprintf(stderr, no memory!);
exit(1);
}
perl_construct(my_perl);
exitstatus = perl_parse(my_perl, xs_init, 2, embedding, NULL);
if (exitstatus) {
fprintf(stderr, There was some errors\n);
} else {
fprintf(stderr, Running perlrun\n);
perl_run(my_perl);
}
} else {
ap_rputs(my_perl is not null\n, r);
}
ap_rprintf(r, H1Hello %s/H1\n, hostname);
ap_rputs(Who would take this book seriously if the first example
didn't\n,r);
ap_rprintf(r, say \hello \?\n);
call_argv(Embed::Persistent::eval_file,
G_DISCARD | G_EVAL, args);
/* check $ */
if(SvTRUE(ERRSV)) {
fprintf(stderr, eval error: %s\n, SvPV(ERRSV,n_a));
}
ap_rputs(/BODY\n, r);
ap_rputs(/HTML\n, r);
return OK;
}
static handler_rec hello_handlers[] =
{
{hello-handler, hello_handler},
{NULL}
};
/* Tell Apache what phases of the transaction we handle */
module MODULE_VAR_EXPORT hello_module =
{
STANDARD_MODULE_STUFF,
NULL, /* module initializer */
NULL, /* per-directory config creator */
NULL, /* dir config merger */
NULL, /* server config creator */
NULL, /* server config merger */
NULL, /* command table */
hello_handlers, /* [7] content handlers */
NULL, /* [2] URI-to-filename translation */
NULL, /* [5] check/validate user_id*/
NULL, /* [6] check user_id is valid *here* */
NULL, /* [4] check access by host address */
NULL, /* [7] MIME type checker/setter */
NULL, /* [8] fixups*/
NULL, /* [9] logger*/
NULL, /* [3] header parser */
NULL, /* process initialization */
NULL, /* process exit/cleanup */
NULL/* [1] post read_request handling*/
};
Re: performance regarding mod_perl vs mod_c with embedded perl
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 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: 1.48 [ms] (mean, across all concurrent requests) mod_perl gives: Requests per second:499.75 [#/sec] (mean) Time per request: 16.01 [ms] (mean) Time per request: 2.00 [ms] (mean, across all concurrent requests) Why is mod_perl so slow compare to a mod_c that embed perl. thanks.
