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
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: 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: 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: AuthzHandler, index.html not being accessed
Ken: back to your original problem. Maybe you should disbale the default index list by comment out "Options Indexes" in your httpd.conf, so as to isolate the problem: if it is authz related or not at all. Peter > > > > A note: since cookie is involved, why not to implement > > all the access/authentication/authurization functions at > > the access control phase using cookie ? > > I've got them split out to match the phase in which they'd be invoked. > That, and the fact that the access handler will be invoked everywhere, but > the authorization handler may be different based on the application being > protected. > > Back to the original problem: it all boils down to the Authz handler. When > it's activated via 'require', directory indexes are not generated. Remove > the require, and *poof*, you get directory indexes. > > > > > > > Peter > > > I've got an interesting problem, related to my development of some > > > Authen/Authz handlers. > > > > > > I have a directory on which I've installed an Access, Authen, and Authz > > > handler: > > > > > > - the Access handler makes sure a cookie exists, and redirects the user > to a > > > login page if it doens't. If the cookie does exist, populate > > > $r->connection->user. This works. > > > > > > - Authen handler currently returns OK - it will be used to validate the > user > > > as stored in the cookie > > > > > > If I 'require valid-user' in the directory, my authz handler doesn't get > > > invoked, which I expect. However, If I request the directory (ie. > /test/) I > > > get a directory listing instead of index.html. If I take out the > require, > > > thereby bypassing authen/authz, I get index.html. If I also put in > custom > > > 'requires', my authz handler is invoked, and the same thing happens. > > > > > > So, it seems that when OK is returned from an authz handler, the > > > DirectoryIndex is not being read. > > > > > > I've been unsucessful in trying to find a solution. > > > > > > Ideas? > > > > > > -klm. > > > > > > BTW, I understand that what I'm doing does appear to be similar to > > > Apache::AuthCookie, but I have a few different requirements that I need > to > > > incorporate > > > > > > > > > > > > > >
Re: AuthzHandler, index.html not being accessed
A note: since cookie is involved, why not to implement all the access/authentication/authurization functions at the access control phase using cookie ? Peter > I've got an interesting problem, related to my development of some > Authen/Authz handlers. > > I have a directory on which I've installed an Access, Authen, and Authz > handler: > > - the Access handler makes sure a cookie exists, and redirects the user to a > login page if it doens't. If the cookie does exist, populate > $r->connection->user. This works. > > - Authen handler currently returns OK - it will be used to validate the user > as stored in the cookie > > If I 'require valid-user' in the directory, my authz handler doesn't get > invoked, which I expect. However, If I request the directory (ie. /test/) I > get a directory listing instead of index.html. If I take out the require, > thereby bypassing authen/authz, I get index.html. If I also put in custom > 'requires', my authz handler is invoked, and the same thing happens. > > So, it seems that when OK is returned from an authz handler, the > DirectoryIndex is not being read. > > I've been unsucessful in trying to find a solution. > > Ideas? > > -klm. > > BTW, I understand that what I'm doing does appear to be similar to > Apache::AuthCookie, but I have a few different requirements that I need to > incorporate > > >
RE: Persistent Net::Telnet Objects
Maybe you can tell us more about the project (e.g. why telnet ?) so there will come many bad advices ? :-) Peter Bi > Perrin wrote: > > I can't see how it could be working now > > That makes two of us! > > > You're probably opening new telnet connections from each apache process. > > I know that I am not since they are continuing to log to the same dump file, > and my code (as stated in previous message) simply goes to the hash and > takes the object. > > > That won't work, since you can't control which process will handle > > requests from the client. > > OK, is there a way to make sure that there is just one process? This site is > not for milions of users, only 10 - 20. > > I'm sure that others have had to keep persistent sockets and/or filehandles > on their server, and I really don't see how my problem is any different... > > Please, can anybody help me? > Shawn
Re: Apache::SizeLimit Exit is Delayed
Hi Jay, Perrin, and Geoff, Thanks for your thoughts on this problem. Jay "yohimbe" Thorne wrote: >For what its worth, I'd recommend KeepAlive Off for almost any mod_perl >deployment. It basically is a waste of memory and a process slot. >Especially >if you put graphics on a separate server. My setup uses a mod_backhand hack for single host accelerating, And I'm using KeepAlive On based on this advice from Theo Schlossnagle. It's been working great for many months. Theo Schlossnagle wrote (on 2/22/2001): >Also, be sure to turn on KeepAlives on the mod_perl server! You will no >longer run out of children and mod_backhand will keep pools of open >connections so that you don't have to reconnect for every request. Perrin Harkins wrote: >Try changing the call >$r->child_terminate() to Apache::exit(). If this seems to work better >for you, let me know and I'll consider changing this in a future release >of Apache::SizeLimit. Geoff wrote: >what about > >$r->headers_out->add(Connection => 'close'); I tried each of these changes in turn. Neither worked to immediately exit the child. I never saw that either of them would exit the child at all but I may not have kept them running long enough. I noticed an odd pattern of behavior. With one of our cgi scripts, and using $r->child_terminate(), the child would always exit immediately. With other scripts, it wouldn't exit. With both Perrin's and Geoff's suggestions from above, that same script would cause the process being used to be changed, but the old process wouldn't exit. We're going to try to figure out what is happening with this and I'll report back if we do. Thanks again for your help! Bob
Re(2): Apache::SizeLimit Exit is Delayed
[EMAIL PROTECTED] writes: >> I'm using Apache::SizeLimit (on both Solaris and Linux) and getting the >> error_log entry: >> >> [Tue Dec 11 15:01:19 2001] (2520) Apache::SizeLimit httpd process too >big, >> exiting at SIZE=44964 KB SHARE=10900 KB REQUESTS=389 LIFETIME=9505 >> seconds >> >> But the child process often doesn't exit right away. It may hang around >> for a couple of minutes or even an hour with the message occuring with >> every hit: > >Maybe this is because of a keep-alive connection. It's possible that >Apache::exit() waits for all keep-alive activity to complete before >exiting. >Is there any way you can test it without keep-alive? > >- Perrin > Hi Perrin, That was it. The child exited immediately when I hit the limit with KeepAlive Off. Now the question is: Is there a way to force an exit even with KeepAlive On? Thanks! Bob
Apache::SizeLimit Exit is Delayed
Hi, I'm using Apache::SizeLimit (on both Solaris and Linux) and getting the error_log entry: [Tue Dec 11 15:01:19 2001] (2520) Apache::SizeLimit httpd process too big, exiting at SIZE=44964 KB SHARE=10900 KB REQUESTS=389 LIFETIME=9505 seconds But the child process often doesn't exit right away. It may hang around for a couple of minutes or even an hour with the message occuring with every hit: [Tue Dec 11 15:20:22 2001] (2520) Apache::SizeLimit httpd process too big, exiting at SIZE=48852 KB SHARE=10944 KB REQUESTS=458 LIFETIME=10648 seconds Eventually the child will exit. (I'd like it to exit on the very first occurrence.) I've looked through the documentation and the archives and can't find a solution to this. Can anyone give me some insight? Thanks! Bob Foster
