cvs commit: modperl-2.0/t/filter/TestFilter api.pm buckets.pm
dougm 2002/09/10 17:50:31
Modified:.Changes
t/apache scanhdrs.t
t/filter/TestFilter api.pm buckets.pm
Log:
Submitted by: Philippe M. Chiasson [EMAIL PROTECTED]
Reviewed by: dougm
tweaks to support Test.pm 1.21
Revision ChangesPath
1.44 +2 -0 modperl-2.0/Changes
Index: Changes
===
RCS file: /home/cvs/modperl-2.0/Changes,v
retrieving revision 1.43
retrieving revision 1.44
diff -u -r1.43 -r1.44
--- Changes 5 Sep 2002 01:50:45 - 1.43
+++ Changes 11 Sep 2002 00:50:31 - 1.44
@@ -10,6 +10,8 @@
=item 1.99_06-dev
+tweaks to support Test.pm 1.21 [Philippe M. Chiasson [EMAIL PROTECTED]]
+
add $r-add_config method to add dynamic configuration at request time
add Apache::DIR_MAGIC_TYPE constant
1.3 +1 -1 modperl-2.0/t/apache/scanhdrs.t
Index: scanhdrs.t
===
RCS file: /home/cvs/modperl-2.0/t/apache/scanhdrs.t,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- scanhdrs.t20 Dec 2001 03:54:40 - 1.2
+++ scanhdrs.t11 Sep 2002 00:50:31 - 1.3
@@ -11,7 +11,7 @@
my $res = GET $location;
-ok $res-content eq 1..1\nok 1\n;
+ok $res-content =~ /^ok 1$/m;
ok $res-header('Content-Type') eq 'text/test-output';
1.7 +1 -0 modperl-2.0/t/filter/TestFilter/api.pm
Index: api.pm
===
RCS file: /home/cvs/modperl-2.0/t/filter/TestFilter/api.pm,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- api.pm11 Apr 2002 11:08:43 - 1.6
+++ api.pm11 Sep 2002 00:50:31 - 1.7
@@ -17,6 +17,7 @@
#XXX: else pp_untie complains:
#untie attempted while %d inner references still exist
sub Apache::Filter::UNTIE {}
+sub Apache::Filter::PRINTF {}
sub handler {
my $filter = shift;
1.7 +3 -0 modperl-2.0/t/filter/TestFilter/buckets.pm
Index: buckets.pm
===
RCS file: /home/cvs/modperl-2.0/t/filter/TestFilter/buckets.pm,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- buckets.pm11 Apr 2002 11:08:43 - 1.6
+++ buckets.pm11 Sep 2002 00:50:31 - 1.7
@@ -13,6 +13,9 @@
use Apache::Const -compile = 'OK';
+#XXX: Not implemented yet, required by Test.pm
+sub Apache::TestToString::PRINTF {}
+
sub handler {
my($filter, $bb) = @_;
Re: Dual Apache setups
On 9 Sep 2002, Jason Czerak wrote: I'm messing around with apache 2.0 and modperl 1.99 and Haven't been able to come across any docs that state that I would or would not need a dual apache setup for high load sites. I don't think anyone have any or much real world experience with this yet. In theory it will probably not be needed if you are using a threaded setup. I'm sure anything you can tell us after trying it in a busy setup will be greatly appreciated. :-) I wish to have apache 2.0 threaded. Don't parse stuff back and forth between threads in shared arrays just yet, or you'll suffer memory leaks. :-) - ask (suffering memory leaks) -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
RE: weird bug in Apache::Filter with UTF-8
Hi under perl561/modperl 1 I have 2 modules in an apache filter context perlhandler module1 module2 module1 prints some text partly hardcoded normal (but accented) text partly from an XML::XPath instruction (UTF-8 codeset but inside the ascii 127) - if module1 is alone the output is ok - with module 2 : *dumped to file module1 output is correct (iso) *module2 through Apache::Filter receives module1 output all translated in UTF-8, even the hardcoded text (like an UTF- 8 contamination to all the text) the same thing printed to a file and to STDOUT (tied by Apache::Filter), is in first case normal, in 2d case all UTF-8. this was with activestate build 631 the bug disappeared with activestate build 633 Pascal Accédez au courrier électronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,13 /mn) ; tél : 08 92 68 13 50 (0,34/mn)
pb with Apache::Filter and internal_redirect
Hi
on win32 perl561/modperl127, last apache::filter
when the first registered handler in the chain calls an
internal redirect (thus short-circuiting others) this produces
an error :
Not a HASH reference at D:/Perl/site/lib/Apache/Filter.pm line
221.
(corresponds to return unless length $self{content} in sub
READLINE.)
is there a cleanup to do before sending an internal redirect ?
best regards
pascal
Accédez au courrier électronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,13
/mn) ; tél : 08 92 68 13 50 (0,34/mn)
Re: lame load balancer, mod_proxy, and sticky sessions
The idea to modify mod_proxy.c is probaly the most convenient solution. Instead of configure backend machine from the ProxyPass setting, you may specifically assign it to the one in the cookie, which takes only a few lines of code to change --- well, plus extra steps to handle the cookie. ProxyPass is processed at the URL translation phase. If the same cookie is used for other purposes such as access control then there is no cost at all. (sorry, this is in the c API, kind of OT.) Peter Bi Hello, I'd like to know if it is possible to use mod_proxy as a sticky session manager. Basically, I'd like to put mod_proxy behind the load balancer and allow the proxy servers to talk to the mod_perl servers. Unfortunately, the load balancer does not allow for sticky sessions and only bounces the user round-robin style. I am playing with the idea of sending a cookie down to the client and using it to stick a user to a particular mod_perl server, but I'd like mod_proxy to figure it out which server and send the user to the defined machine. I'd also like to enable a checking mechanism to determine if a mod_perl server is up before the user is sent to the location specified in the cookie. If the machine that the client is stuck to is down, I'd like to reroute. I know high powered load balancers do this already, but I'd like to explore dedicating a few medium sized servers to do as there is surplus of these and f5's cost $$$. I apologize in advance if this is a bit off topic! Thanks, Al ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com **
Re: lame load balancer, mod_proxy, and sticky sessions
[EMAIL PROTECTED] wrote: The idea to modify mod_proxy.c is probaly the most convenient solution. Instead of configure backend machine from the ProxyPass setting, you may specifically assign it to the one in the cookie, which takes only a few lines of code to change --- well, plus extra steps to handle the cookie. But you're not accounting for the possibility of server failure on the backend. A proper load-balancer (including the open source ones and mod_backhand) would detect dead servers and handle the failover to another server. Building this yourself is probably not worth it, with so many open source solutions already available. - Perrin
RE: mod_perl statistics on securityspace.com
Aside from being an interesting fact, how does this affect us? I mean, as mod_perl developers? I can't imagine that mod_perl will ever be the major scripting language since it, by nature, is unrestrictive. On a multi-user/multi-host server, I think I'd rather PHP be run than mod_perl, simply because I don't want sites stepping on each other's toes and have to worry about restarting httpd. I don't know. I don't see it overtaking less-powerful (more restrictive) languages, at least in numbers. Now, if these numbers are generated by looking at high-profile websites, then I'll buy the importance of the percentages. Regardless, thanks for the report. It was cool to see just how many servers have good admin's behind them :)
Re: lame load balancer, mod_proxy, and sticky sessions
[EMAIL PROTECTED] wrote: But you're not accounting for the possibility of server failure on the backend. A proper load-balancer (including the open source ones and mod_backhand) would detect dead servers and handle the failover to another server. This is true. Then one has to ping the network which is very expensive. --- yes, a special product would be better. Building this yourself is probably not worth it, with so many open source solutions already available. The original post consists of two parts: to proxy to the right machine and to handle the failover. If there is a quick solution to the first part, why not make it and have the second part be solved later ? Peter Bi [EMAIL PROTECTED] wrote: The idea to modify mod_proxy.c is probaly the most convenient solution. Instead of configure backend machine from the ProxyPass setting, you may specifically assign it to the one in the cookie, which takes only a few lines of code to change --- well, plus extra steps to handle the cookie. But you're not accounting for the possibility of server failure on the backend. A proper load-balancer (including the open source ones and mod_backhand) would detect dead servers and handle the failover to another server. Building this yourself is probably not worth it, with so many open source solutions already available. - Perrin
Re: mod_perl statistics on securityspace.com
From: Ilya Martynov [EMAIL PROTECTED] IM (frankly Safe.pm is a joke). Now this thread has taken my interest. Ilya, would you care to expound on this statement? I'm planning to use Safe in production soon. --- Rodney Broom President, R.Broom Consulting http://www.rbroom.com/
Re: mod_perl statistics on securityspace.com
Mark Coffman wrote: I can't imagine that mod_perl will ever be the major scripting language since it, by nature, is unrestrictive. On a multi-user/multi-host server, I think I'd rather PHP be run than mod_perl, simply because I don't want sites stepping on each other's toes and have to worry about restarting httpd. Isn't PHP just as dangerous as mod_perl when run in the server process (as opposed to CGI mode) on a multi-user virtual host server? - Perrin
$? and No child processes in $! from `echo something` under mod_perlafter a while...
Hi,
For some reason, the process running mod_perl gets into a state, where it
doesn't behave properly with backticks after having run for a while. In
short, I'm confused about the relationship between SIG{CHLD}, qx and
mod_perl.
#!/usr/bin/perl -w
use strict;
print Content-type: text/html\n\n;
# $SIG{'CHLD'} = '';
my $sigChldStr;
if (defined $SIG{'CHLD'}) {
$sigChldStr = (($SIG{CHLD} eq '') ? empty : defined );
} else {
$sigChldStr = undef;
}
my $result = `echo Result is something`;
if ($?) {
print Error: $?, $!, . ($! + 0) . , $result, . $sigChldStr;
} else {
print Result: $result, . $sigChldStr;
}
print \n;
When I run the script the first time, after a fresh reboot or restart of
apache, it runs fine. After a while of running my real application (2
days, 1 day, 4 hours - it varies) , the short script above (and my real
application) all of a sudden start failing consistently and $? after a
{ $result = `echo Result is something` } becomes true, with $! == No child
processes (This comes from wait(2), I suspect.). This result now happens
every time i hit refresh.
If I uncomment the $SIG{'CHLD'} = '' line and run it only once pr. httpd
process, it starts behaving again - consistently
(pseudo-consistently?)..., but now SIG{CHLD} is defined and eq ''. For some
reason, SIG{CHLD} defaults to undef, but I cannot set it to undef, or I get
a warning, and its value gets set to ''. Why does $SIG{CHLD}='' work, and
are there any potential side effects of this?
The CGI part of my real application is around 13500 lines, and I really
don't know where it is going wrong. I don't touch SIG{CHLD}. I must be
doing something that puts mod-perl in a state where it starts failing.
Should I be doing anything special for file handles? File locking problems
(I am *certain* there is only two flock instances in the code: a perfectly
matched LOCK_EX/LOCK_UN pair)? You name it? I've tried to find these things
myself, but it looks to me as if everything is fine. And to inspect all the
code closely is just too much when I don't know what I'm looking for. Under
/proc I can see that the http process does not have a lot of open file
handles... (16 pr process - just like after a restart)
Any ideas why / where to start looking? I need to come up with a patch
soon, and I'd hate to have to disable mod-perl and go back to plain ol'
CGI.pm...
Especially, is there any interesting things to inspect once the mod-perl
process has started doing this? An apache restart *always* cures it, but
since it can take days for it to reappear, I'd like to make the most of the
debugging effort when its there. It seems to be sensitive to changes in
SIG{CHLD} but I don't know why or how.
I wasn't very sure what info to include, but I can send all the info you
need. It was difficult for me to tell what info this scenario requires.
Kind regards,
Peter Morch, CapMon
**
Output in the beginning of mod-perl.
**
Result: Result is something ,undef
**
Output under mod_perl after a while.
**
Error: -1, No child processes, 10, Result is something , undef
(Note how the `echo Result is something` actually really did succeed.)
**
Output after having run with uncommented $SIG{CHLD} line from listing ONCE
in the past
**
Result: Result is something ,empty
**
Output under unmod-perl at any time
**
HELLO
Result: Result is something ,undef
**
Versions, etc.
**
Running on SuSE Linux 7.2
lyta@pvm:~ rpm -qa | grep mod_perl
mod_perl-1.25-30
lyta@pvm:~ rpm -qa | grep apache
apache-1.3.19-48
lyta@pvm:~ perl -V
Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration:
Platform:
osname=linux, osvers=2.4.3, archname=i586-linux
uname='linux subbotin 2.4.3 #1 tue may 8 21:54:34 gmt 2001 i686 unknown
'
config_args='-ds -e -Dprefix=/usr -Di_db -Di_dbm -Di_ndbm -Di_gdbm'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
useperlio=undef d_sfio=undef uselargefiles=define
use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef
Compiler:
cc='cc', optimize='-O2 -pipe', gccversion=2.95.3 20010315 (SuSE)
cppflags='-fno-strict-aliasing -I/usr/local/include'
ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64'
stdchar='char', d_stdstdio=define, usevfork=false
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=4, usemymalloc=n, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
Re: mod_perl statistics on securityspace.com
On Tue, 10 Sep 2002 12:14:32 -0400, Perrin Harkins [EMAIL PROTECTED] said: PH Mark Coffman wrote: I can't imagine that mod_perl will ever be the major scripting language since it, by nature, is unrestrictive. On a multi-user/multi-host server, I think I'd rather PHP be run than mod_perl, simply because I don't want sites stepping on each other's toes and have to worry about restarting httpd. PH Isn't PHP just as dangerous as mod_perl when run in the server process PH (as opposed to CGI mode) on a multi-user virtual host server? As I understand PHP have better support for sandboxing than Perl (frankly Safe.pm is a joke). -- Ilya Martynov (http://martynov.org/)
Expect.pm worked on v1.24 not on v1.26
Here is a program that works in perl 5.6.1 but it doesn't on mod_perl 1.26.
#!/usr/bin/perl -w
use Expect;
$expect_delay=120;
$system_name = system;
$system_pass = thisisthepassword;
$login=Expect-spawn(telnet node.domain.com) or die Can't start telnet: $! \n;
$login-clear_accum();
$match = $login-expect($expect_delay,Username:);
print $login $system_name\r;
$login-clear_accum();
$match = $login-expect($expect_delay,Password:);
print $login $system_pass\r;
$login-clear_accum();
$match = $login-expect($expect_delay,'$');
print $login set term/device=vt100\r;
$login-clear_accum();
$match = $login-expect($expect_delay,'$');
print $login set process/priv=all\r;
$login-clear_accum();
$match = $login-expect($expect_delay,'$');
print $login dir\r;
Dear MODPERLers,
I am sorry to trouble you with this, but I am having a problem
with Expect.pm running under Registry.pm. This code has worked
fine on older versions of Apache/mod_perl. i.e.:
[Fri Sep 6 13:58:24 2002] [notice] Apache/1.3.12 (Unix) mod_perl/1.24 mod_ssl/2.6.6
OpenSSL/0.9.6 configured -- resuming normal operations
The problem version and problem log are as follows:
--snip--
[Fri Sep 6 12:56:06 2002] [notice] Apache/1.3.26 (Unix) PHP/4.2.1 mod_perl/1.26
mod_ssl/2.8.10 OpenSSL/0.9.6e configured -- resuming normal operations
[Fri Sep 6 12:56:06 2002] [notice] Accept mutex: sysvsem (Default: sysvsem)
[Fri Sep 6 12:56:20 2002] null: Starting EXPECT pattern matching...
[Fri Sep 6 12:56:20 2002] null: Expect::expect('Expect=GLOB(0x88819e8)', 120,
'Username:') called at /usr/local/apache//apache_lib/H1.pm line 523
--snip--
A portion of the code that I am running is:
--snip--
my $login=Expect-spawn(telnet $node_name);
$login-debug($debug);
$login-clear_accum();
$match = $login-expect($expect_delay,Username:);
--snip--
It works fine until the expect method is called. It failes to
connect to the remote system and these odd null: line begin
dumping in the error log.
Have you seen anything like this?
Thanks in advance and again sorry for the interruption.
--
--
Mark Temple, Information Technology Manager
ABC Labs, Columbia, Missouri 65202
voice:573.876.8198 fax:573.443.9033
--
Re: mod_perl statistics on securityspace.com
On Tue, 10 Sep 2002 09:53:50 -0700, Rodney Broom [EMAIL PROTECTED] said: RB From: Ilya Martynov [EMAIL PROTECTED] IM (frankly Safe.pm is a joke). RB Now this thread has taken my interest. Ilya, would you care to RB expound on this statement? I'm planning to use Safe in production RB soon. Try to implement something that works with database and files inside of Safe compartment. Either you will have to allow too much or your code will not work because of restrictions. Somewhat related reading: http://www.perlmonks.com/index.pl?node_id=166096 -- Ilya Martynov (http://martynov.org/)
Re: mod_perl statistics on securityspace.com
From: Ilya Martynov [EMAIL PROTECTED] Try to implement something that works with database and files inside of Safe compartment. Ah, yes. I can definately see that. --- Rodney Broom President, R.Broom Consulting http://www.rbroom.com/
RE: NTLM module
Title: RE: NTLM module Adam, I am not sure if you have resolved this issue. I have had the same issue with our system where post data would dissappear. I ended up creating a Cookie add on module for Apache::AuthenNTLM that would write a cookie once authenticated and use that before re-authenticating them. This allowed me to lower the keepalive timeout setting and has almost completely eliminated this loss of data. I created it for a semi friendly environment so the security is somewhat lacking. If you would like to take a look at it I can send you the code. I have not tried the latest version of AuthenNTLM yet. But it should still work. Joseph Harnish -Original Message- From: Kaye-Smith Adam [mailto:[EMAIL PROTECTED]] Sent: Monday, September 02, 2002 9:48 PM To: Gerald Richter Cc: [EMAIL PROTECTED] Subject: RE: NTLM module Hello Gerald, I believe I am on top of my issues with NTLM. Everything seems to work fine when httpd is in single user mode as the 1 process has an understanding of what has been authenticated before hand whethor it needs to re-authenticate subsequent requests from the same browser/user. ie with the request for one page there may be many items that need to be sent by the server (images, html,etc). When we go to several httpd process, it appears that the response to one request from a browser which may be made up of many files that need to be sent back, these requests can be handled by any of the http processes (which is ok by itself ) but when this occurs, a password request(and perhaps an SMB query) is made for each of the httpd process. The httpd processes appear to operate independently of each other, unless the browser sends all its requests down the 1 tcp channel. I have started to add to the code to log authentications to disc, so that each httpd process can also reference this disc file to verify if it has authenticated a user beforehand from another process. I hope I am going about this the right way.. My more immediate problem is that I am currently losing the contents of posted variables in a request packet whenever I use the AuthenNTLM module, but when I choose to use the standard mod_auth, my posted variables get through everytime. This problem occured with the AuthenNTLM code without any alterations. This problem is also intermittant. 4 out of 5 time the problem will occur. By inserting the line at the top of handler sub ' $printme = $r - content ' I can see the posted variables get though to the perl module . Any ideas Thanks Adam The information in this e-mail together with any attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any form of review, disclosure, modification, distribution and/or publication of this e-mail message is prohibited. If you have received this message in error, you are asked to inform the sender as quickly as possible and delete this message and any copies of this message from your computer and/or your computer system network.
mod_perl and apache 2.x
Are there plans to make the new mod_perl backwards compatible? I tried a few months ago to move my faily large app to apache 2.x and mod perl and far far too many things are different. I'd love to experiment with the new code base, but this lack of compatibility is a show stopper for me. I don't have the time to re-code the entire thing. Failing that, is there a way to at least get print to work? Or have later mod_perl releases fixed that? -- Jay yohimbe Thorne [EMAIL PROTECTED] Mgr Sys Tech, Userfriendly.org
OS X 10.1.5 problem: alloc.c not compiling mod_perl-1.27 / apache_1.3.26
The subject more or less says it all. I've found one bug report online which is pretty similar, but does not say much about a solution: http://citadelle.intrinsec.com/mailing/current/HTML/ml_apache-server-bugs/0424.html The errors look like: alloc.c: in function 'spawn_child_core': alloc.c: 2291'STDIN_FILENO' undeclared alloc.c: 2297 'STDIN_FILENO' undeclared alloc.c: 2303 'STDIN_FILENO' undeclared The compile command is the basic: sudo perl Makefile.PL src="../apache_1.3.26/src" USE_APACI=1 EVERYTHING=1 DO_HTTPD=1 The one thing that is perhaps slightlyunusual about the installation is that it's entirely offline. This is an unfortunate fact of the security conscious network environment I'm operating in.
Morning bug w/out using Apache::DBI?
Hi! I recently made an attempt to upgrade other web software to mod_perl 1.26 (compiled statically, running on Solaris 2.6). We're using Sybase 11.9.2 for this application as the db backend. When I initially converted the site over to mod_perl, I started off using Apache::DBI by placing it in the startup.pl script that I have Apache use when loading mod_perl. Apparently, that night, the dataserver began experiencing deadlocking. Here are some of the error messages encountered in the apache logs and through one of our cron jobs: DBD::Sybase::db rollback failed: OpenClient message: LAYER = (1) ORIGIN = (1) SEVERITY = (1) NUMBER = (49) Message String: ct_send(): user api layer: external error: This routine cannot be called because another command structure has results pending. DBD::Sybase::db rollback failed: OpenClient message: LAYER = (1) ORIGIN = (1) SEVERITY = (1) NUMBER = (50) Message String: ct_cmd_alloc(): user api layer: external error: The connection has been marked dead. DBD::Sybase::db prepare failed: OpenClient message: LAYER = (4) ORIGIN = (1) SEVERITY = (5) NUMBER = (1) Message String: ct_results(): protocol specific layer: external error: There is a tds protocol error. Premature end of the datastream was encountered. Your server command (family id #0, process id #16) was deadlocked with another process and has been chosen as deadlock victim. Re-run your command. When I restarted the Apache server, it seemed to have cleaned this situation up temporarily. I ended up removing Apache::DBI from the startup.pl script to see if this would resolve this issue. This morning apparently, similar problems were encountered. I didn't see the same error messages arise this morning in the Apache logs, but the same error appeared this morning: DBI-connect(interfaces=;server=;database=) failed: OpenClient message: LAYER = (5) ORIGIN = (3) SEVERITY = (5) NUMBER = (6) Message String: ct_connect(): network packet layer: internal net library error: Net-Library operation terminated due to disconnect These connect errors seemed to have affected the Sybase server in terms of connectivity. I'm not positive but maybe it seemed like there were stale handlers lying around that weren't being closed, perhaps preventing other handlers from being able to connect since the maximum number of open connections was being exceeded (well, that's my theory. Please correct me if I'm wrong here). Also, these errors didn't come about until roughly 5 hours after the Apache server was restarted with the mod_perl applications in place. There was little activity on the web server side in relation to those mod_perl applications. Regardless, I was wondering what a solution would be for this situation. Currently, I do not do a ping if a handler goes stale and attempt a reconnect. Should I implement this feature? Are there other considerations to deal with in this situation? Note that this is an internal server which isn't heavily used so I'm not worried about receiving a few million hits a second. Thanks for any help. --Keith
performance regarding mod_perl vs mod_c with embedded perl
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.
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.
Re: NTLM module
RE: NTLM moduleI am not sure if you have resolved this issue. The POST issuse is still on my todo list I have had the same issue with our system where post data would dissappear. I ended up creating a Cookie add on module for Apache::AuthenNTLM that would write a cookie once authenticated and use that before re-authenticating them. This allowed me to lower the keepalive timeout setting and has almost completely eliminated this loss of data. Since it works with IIS, there should be an offical way to do it. I have to investigate it. I created it for a semi friendly environment so the security is somewhat lacking. That's the reason why I didn't included your patch so far in AuthenNTLM, but I have to go over it more in detail and will send you an feedback then. Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 -
