Re: Can't call Apache::Request-new()
Hi there, On Fri, 14 Dec 2001, Anand R wrote: The Request Object contains info sent to the server in the client's request. [snip] Maybe this should not a big problem,U just have to have a look at the Apache Doc. I think he's trying to say perldoc Apache::Request :) 73, Ged. PS: Cute email address Paul.
Re: Can't call Apache::Request-new()
Yes PerlDoc . And you have a very good doc on Indigoperl. U even have it in mod_perl :) - PS:- Paul I saw your site and that is real nice. - Original Message - From: Ged Haywood [EMAIL PROTECTED] To: Anand R [EMAIL PROTECTED] Cc: Paul Makepeace [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, December 14, 2001 2:01 PM Subject: Re: Can't call Apache::Request-new() Hi there, On Fri, 14 Dec 2001, Anand R wrote: The Request Object contains info sent to the server in the client's request. [snip] Maybe this should not a big problem,U just have to have a look at the Apache Doc. I think he's trying to say perldoc Apache::Request :) 73, Ged. PS: Cute email address Paul.
Re: load balancing on apache
Hi Hemant Singh, A round-robin dns server would be easiest. There's no true load balancing this way though. Regards, John Hoffman - Original Message - From: Hemant Singh Sent: Friday, December 14, 2001 1:29 AM To: [EMAIL PROTECTED] Subject: load balancing on apache Hi All I am planning to host an application and its size is going to be big one , so expect the concurrent number of connection s to be around 2200.To combat the same , want to perform load sharing on 3-4 servers.So the ide is to put one machine on external IP and this machine , after receiving the requests would forward them to any of the other three machines having the application deployed and running on the same environment.Pls suggest how can i achieve this on apache. Thanks in advance HemantGet more from the Web. FREE MSN Explorer download : http://explorer.msn.com
Re: Can't call Apache::Request-new()
On Fri, Dec 14, 2001 at 08:31:26AM +, Ged Haywood wrote: Hi there, On Fri, 14 Dec 2001, Anand R wrote: The Request Object contains info sent to the server in the client's request. [snip] Maybe this should not a big problem,U just have to have a look at the Apache Doc. I think he's trying to say perldoc Apache::Request Hmm, I was hoping I was way beyond that! Perhaps I'm not being clear -- I'm use'ing a module and calling a documented method and then perl is claiming the module isn't loaded. I showed a command line that demonstrated this ( that the module is installed) and then said it also happened when under mod_perl. To go into even more detail, here is how I'm calling it under mod_perl. I'm new to this so quite possibly the mistake's somewhere here... httpd.conf: Files /perl-bin/*.cgi SetHandler perl-script PerlHandler Apache::Registry Options +ExecCGI PerlSendHeader On /Files apr.cgi: #!/usr/bin/perl -Tw use strict; use Apache::Request; my $r = shift; my $apr = Apache::Request-new($r); my @params = $apr-param; print HTML; Content-type: text/plain @params; HTML And sho' nuff ...error.log contains, Can't locate object method new via package Apache::Request (perhaps you forgot to load Apache::Request?) at /home/wwwrp/perl-bin/apr.cgi line 7. [Fri Dec 14 00:43:14 2001] [error] [client 172.30.0.3] Premature end of script headers: /home/wwwrp/perl-bin/apr.cgi :) 73, Ged. PS: Cute email address Paul. Heh thanks -- no prizes for guessing which device file x10.com@ goes to :-) 55, Paul -- Paul Makepeace ... http://paulm.com/ What is the meaning of life? The unforgiven. -- http://paulm.com/toys/surrealism/
Re: load balancing on apache
On Fri, 14 Dec 2001, Hemant Singh wrote:
Pls suggest how can i achieve this on apache.
mod_backhand may be able to help you out here with proper pass it on
type load balancing. If you use it with wackamole you might not even need
the front machine.
http://www.backhand.org/
Haven't used it myself, but people I know say good things about their
experiences with it.
--
s'' Mark Fowler London.pm Bath.pm
http://www.twoshortplanks.com/ [EMAIL PROTECTED]
';use Term'Cap;$t=Tgetent Term'Cap{};print$t-Tputs(cl);for$w(split/ +/
){for(0..30){$|=print$t-Tgoto(cm,$_,$y). $w;select$k,$k,$k,.03}$y+=2}
Re: Can't call Apache::Request-new()
As far as the httpd.conf goes , Alias /perl/ /real/path/to/perl/scripts/ Location /perl SetHandler perl-script PerlHandler Apache::Registry Options ExecCGI /Location PerlModule Apache :: Registry PerlModule CGI PerlSendHandler On Files *.perl SetHandler perl-script PerlHandler Apache::Registry Options ExecCGI /Files Check these with your setup,..But I think you have given it right Maybe this time it is solved. Regards, Anand - Original Message - From: Paul Makepeace [EMAIL PROTECTED] To: Ged Haywood [EMAIL PROTECTED] Cc: Anand R [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, December 14, 2001 2:22 PM Subject: Re: Can't call Apache::Request-new() On Fri, Dec 14, 2001 at 08:31:26AM +, Ged Haywood wrote: Hi there, On Fri, 14 Dec 2001, Anand R wrote: The Request Object contains info sent to the server in the client's request. [snip] Maybe this should not a big problem,U just have to have a look at the Apache Doc. I think he's trying to say perldoc Apache::Request Hmm, I was hoping I was way beyond that! Perhaps I'm not being clear -- I'm use'ing a module and calling a documented method and then perl is claiming the module isn't loaded. I showed a command line that demonstrated this ( that the module is installed) and then said it also happened when under mod_perl. To go into even more detail, here is how I'm calling it under mod_perl. I'm new to this so quite possibly the mistake's somewhere here... httpd.conf: Files /perl-bin/*.cgi SetHandler perl-script PerlHandler Apache::Registry Options +ExecCGI PerlSendHeader On /Files apr.cgi: #!/usr/bin/perl -Tw use strict; use Apache::Request; my $r = shift; my $apr = Apache::Request-new($r); my @params = $apr-param; print HTML; Content-type: text/plain @params; HTML And sho' nuff ...error.log contains, Can't locate object method new via package Apache::Request (perhaps you forgot to load Apache::Request?) at /home/wwwrp/perl-bin/apr.cgi line 7. [Fri Dec 14 00:43:14 2001] [error] [client 172.30.0.3] Premature end of script headers: /home/wwwrp/perl-bin/apr.cgi :) 73, Ged. PS: Cute email address Paul. Heh thanks -- no prizes for guessing which device file x10.com@ goes to :-) 55, Paul -- Paul Makepeace ... http://paulm.com/ What is the meaning of life? The unforgiven. -- http://paulm.com/toys/surrealism/
RE: Can't call Apache::Request-new()
I think I know what's happening here. Your script is running as a CGI, not
as mod_perl. Check:
print not unless $ENV{MOD_PERL};
print running under mod_perl\n;
Matt.
--
:-Get a smart net/:-
-Original Message-
From: Paul Makepeace [mailto:[EMAIL PROTECTED]]
Sent: 14 December 2001 08:53
To: Ged Haywood
Cc: Anand R; [EMAIL PROTECTED]
Subject: Re: Can't call Apache::Request-new()
On Fri, Dec 14, 2001 at 08:31:26AM +, Ged Haywood wrote:
Hi there,
On Fri, 14 Dec 2001, Anand R wrote:
The Request Object contains info sent to the server in
the client's request.
[snip]
Maybe this should not a big problem,U just have to have a
look at the
Apache Doc.
I think he's trying to say
perldoc Apache::Request
Hmm, I was hoping I was way beyond that!
Perhaps I'm not being clear -- I'm use'ing a module and calling a
documented method and then perl is claiming the module isn't loaded. I
showed a command line that demonstrated this ( that the module is
installed) and then said it also happened when under mod_perl. To go
into even more detail, here is how I'm calling it under mod_perl. I'm
new to this so quite possibly the mistake's somewhere here...
httpd.conf:
Files /perl-bin/*.cgi
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
PerlSendHeader On
/Files
apr.cgi:
#!/usr/bin/perl -Tw
use strict;
use Apache::Request;
my $r = shift;
my $apr = Apache::Request-new($r);
my @params = $apr-param;
print HTML;
Content-type: text/plain
@params;
HTML
And sho' nuff ...error.log contains,
Can't locate object method new via package
Apache::Request (perhaps you forgot to load
Apache::Request?) at /home/wwwrp/perl-bin/apr.cgi line 7.
[Fri Dec 14 00:43:14 2001] [error] [client 172.30.0.3]
Premature end of script headers: /home/wwwrp/perl-bin/apr.cgi
:)
73,
Ged.
PS: Cute email address Paul.
Heh thanks -- no prizes for guessing which device file x10.com@
goes to :-)
55,
Paul
--
Paul Makepeace ...
http://paulm.com/
What is the meaning of life? The unforgiven.
-- http://paulm.com/toys/surrealism/
This email has been scanned for all viruses by the Star Internet Virus
Screen.
The service is provided in partnership with MessageLabs, the email security
company.
For more information on a higher level of virus protection visit
www.star.net.uk
_
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.
ApacheCon Trial Version
Does any one weather we can have a Trial Version of ApacheCon. Or it is paided. TIA, Anand
Re: load balancing on apache
Hemant Singh [EMAIL PROTECTED] writes: Hi All I am planning to host an application and its size is going to be big one , so expect the concurrent number of connection s to be around 2200.To combat the same , want to perform load sharing on 3-4 servers.So the ide is to put one machine on external IP and this machine , after receiving the requests would forward them to any of the other three machines having the application deployed and running on the same environment.Pls suggest how can i achieve this on apache. Depends how much session persistence you're keeping on the middle tier. You can do things smarter than pure round robin with a few mod_rewrite rules on the front. -- David Hodgkinson, Wizard for Hirehttp://www.davehodgkinson.com Editor-in-chief, The Highway Star http://www.deep-purple.com Deep Purple Family Tree news http://www.slashrock.com Interim Technical Director, Web Architecture Consultant for hire
Re: ASP.NET Linux equivalent?
A bit late, but.. Can't remember the exact URL, but search GOOGLE for GNUDOTNET. They have started to whip up a FREE version of MS's .net platform. Don't know if this is what you want, but. Cheers! Mark Harrop [EMAIL PROTECTED] `\|||/ (@@) ooO_(_)_Ooo___ _|_|_|_|_|_|_| Epping, Melbourne, Victoria, AUSTRALIA. - Original Message - From: Vsevolod Ilyushchenko [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, December 04, 2001 10:55 AM Subject: ASP.NET Linux equivalent? | Hi, | | Is anyone aware of a Linux product equivalent to ASP.NET from MS? Its most
Re: [SOLUTION] Can't call Apache::Request-new()
On Fri, Dec 14, 2001 at 09:20:06AM -, Matt Sergeant wrote:
I think I know what's happening here. Your script is running as a CGI, not
as mod_perl. Check:
print not unless $ENV{MOD_PERL};
print running under mod_perl\n;
Yup, this is it. Grrr, seems like my Files /perl-bin/*.cgi was
the problem.
Directory /home/wwwrp/perl-bin
Files *.cgi
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
PerlSendHeader On
/Files
/Directory
Thanks Matt all!
D'oh,
Paul
[1] http://httpd.apache.org/docs/mod/core.html#files
Matt.
--
:-Get a smart net/:-
--
Paul Makepeace ... http://paulm.com/
If the car doesn't start in the rain, then all would be revealed.
-- http://paulm.com/toys/surrealism/
Re: [SOLUTION] Can't call Apache::Request-new()
Paul.Matt,ged and others on the ring,
at last the problem is solved
regards,
ANAND ,
PDM Programmer,
www.dsmsoft.com
- Original Message -
From: Paul Makepeace [EMAIL PROTECTED]
To: Matt Sergeant [EMAIL PROTECTED]
Cc: Ged Haywood [EMAIL PROTECTED]; Anand R [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Friday, December 14, 2001 3:18 PM
Subject: Re: [SOLUTION] Can't call Apache::Request-new()
On Fri, Dec 14, 2001 at 09:20:06AM -, Matt Sergeant wrote:
I think I know what's happening here. Your script is running as a CGI,
not
as mod_perl. Check:
print not unless $ENV{MOD_PERL};
print running under mod_perl\n;
Yup, this is it. Grrr, seems like my Files /perl-bin/*.cgi was
the problem.
Directory /home/wwwrp/perl-bin
Files *.cgi
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
PerlSendHeader On
/Files
/Directory
Thanks Matt all!
D'oh,
Paul
[1] http://httpd.apache.org/docs/mod/core.html#files
Matt.
--
:-Get a smart net/:-
--
Paul Makepeace ... http://paulm.com/
If the car doesn't start in the rain, then all would be revealed.
-- http://paulm.com/toys/surrealism/
Re: ASP.NET Linux equivalent?
here maybe?: http://www.dotgnu.org/ Mark Mark Tiramani FREDO Internet Services [EMAIL PROTECTED]
Re: load balancing on apache
-- Hemant Singh [EMAIL PROTECTED] Hi All I am planning to host an application and its size is going to be big one , so expect the concurrent number of connection s to be around 2200.To combat the same , want to perform load sharing on 3-4 servers.So the ide is to put one machine on external IP and this machine , after receiving the requests would forward them to any of the other three machines having the application deployed and running on the same environment.Pls suggest how can i achieve this on apache. Randal Schwartz had a good article on this about a year ago. You can use the re-write phase to balance the load w/in Apache if you want to. Alternatives include round- robin DNS and separate load balancing software. -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 800 762 1582
RE: Can't call Apache::Request-new()
Paul, I have version .33 working on perl 5.6.1 on a redhat 7.2 box (I compiled perl myself). However, if I do the command you do below, I get the same error. --Alex -Original Message- From: Paul Makepeace [mailto:[EMAIL PROTECTED]] Sent: Friday, December 14, 2001 12:43 AM To: [EMAIL PROTECTED] Subject: Re: Can't call Apache::Request-new() So no replies to this -- could someone even confirm they have a working Apache::Request v0.33 on perl 5.6.1? That would be a big help in at least determining whether it's perhaps something amiss here. Else I'll file it as a bug. Cheers, Paul On Tue, Dec 11, 2001 at 09:11:50PM -0800, Paul Makepeace wrote: I'm getting the following error, $ perl -MApache::Request -e 'Apache::Request-new' Can't locate object method new via package Apache::Request (perhaps you forgot to load Apache::Request?) at -e line 1. $ ...both from the command line and under a PerlHandler Apache::Registry'd script. Of course, it is installed: $ perl -MApache::Request -le 'print grep /Request/, values %INC; print $Apache::Request::VERSION' /usr/local/lib/perl/5.6.1/Apache/Request.pm 0.33 $ In all other respects I'm able to discern so far mod_perl, Perl and Apache are working here (I have a number of sites using Template Toolkit with a custom PerlHandler and a few scripts under Apache::Registry). I'm getting this error from both a fresh CPAN install and Debian's libapache-request-perl package (not installed at the same time!). Any suggestions where to start looking? Thanks, Paul PS Rather than cluttering your inbox, perl -V is at http://paulm.com/tmp/perl_v.txt
Re: load balancing on apache
I am planning to host an application and its size is going to be big one , so expect the concurrent number of connection s to be around 2200. To combat the same , want to perform load sharing on 3-4 servers. If you really expect 2200 concurrent connections, you should buy dedicated load-balancing hardware like Big/IP or Cisco LocalDirector. - Perrin
RE: load balancing on apache
With this amount of connections, you may want to check LVS at http://www.linuxvirtualserver.com or Ultra Monkey et http://ultramonkey.sourceforge.net/(althought i never used the last one, I think it might be easier to use). This is open, efficient and reliableload balancing and high availability software. Using it, you just have to install several (common)apache server running your application, and tell the load-balancer to forward to one of the real servers. Nothing special to install exept an NFS or Coda service to share your Web sites. Fred -Message d'origine-De: Hemant Singh [mailto:[EMAIL PROTECTED]]Envoyé: vendredi 14 décembre 2001 09:51À: [EMAIL PROTECTED]Objet: load balancing on apache Hi All I am planning to host an application and its size is going to be big one , so expect the concurrent number of connection s to be around 2200.To combat the same , want to perform load sharing on 3-4 servers.So the ide is to put one machine on external IP and this machine , after receiving the requests would forward them to any of the other three machines having the application deployed and running on the same environment.Pls suggest how can i achieve this on apache. Thanks in advance Hemant
RE: load balancing on apache
Hi all, You can do load balancing using ipchains as well. Can't remember the program name offhand, but if I have time I'll look it up and let the list know. Only works if your servers are Linux of course. Kind regards Derek. --Derek Jones 1051, Bollinger Road,Tel: 717 359 8817 Littlestown,Mobile: 717 977 4556 PA, 17340, USAEmail: [EMAIL PROTECTED]AIM: scunacc
Re: Preloading Fcntl.pm
In article [EMAIL PROTECTED], Stas Bekman [EMAIL PROTECTED] wrote: Andrew Green wrote: The *really* peculiar thing is that actual scripts that use Fcntl work with no problems -- but I can't preload the module, or preload other modules that use it. Hmm, how about upgrading modperl? I've now finally managed to upgrade mod_perl to 1.23, and the problem has completely disappeared. I didn't even need $Apache::Server::ReStarting (which isn't available on 1.21) to be checked in the end. Many thanks to everyone for your help. Cheers, Andrew. -- :: article seven Andrew Green automatic internet [EMAIL PROTECTED] | www.article7.co.uk
RE: Can't call Apache::Request-new()
Hi all, On Fri, 14 Dec 2001, Alex Porras wrote: I have version .33 working on perl 5.6.1 on a redhat 7.2 box (I compiled perl myself). However, if I do the command you do below, I get the same You need a request object to give to Apache::Request::new(). It makes no sense to call it from the command line because then you haven't got one. 73, Ged.
Re: load balancing on apache
Perrin Harkins [EMAIL PROTECTED] writes: I am planning to host an application and its size is going to be big one , so expect the concurrent number of connection s to be around 2200. To combat the same , want to perform load sharing on 3-4 servers. If you really expect 2200 concurrent connections, you should buy dedicated load-balancing hardware like Big/IP or Cisco LocalDirector. Aside from the fact I _really_ wouldn't expect that manny actual, live TCP connections at one time...that many users, maybe... I _really_ hate so-called dedicated boxes. They're closed, nasty, inflexible and often don't work in _your_ situation. Doing smart session-based redirection can be hard with these boxes. -- David Hodgkinson, Wizard for Hirehttp://www.davehodgkinson.com Editor-in-chief, The Highway Star http://www.deep-purple.com Deep Purple Family Tree news http://www.slashrock.com Interim Technical Director, Web Architecture Consultant for hire
Re: load balancing on apache
You should also check out Coyote Point's Equalizer ... this a
hardware/software solution that worked well for ValueClick up to about 70
million requests per day. It's basically a FreeBSD box with a custom
dynamic natd ... supports hot-swap redundancy with two of 'em installed
... and a _lot_ cheaper than LocalDirector and others (although we did
move to a high-end Foundry Server Iron system eventually) ... good support
from a small company too.
- nick
Nick Tonkin {|8^)
On Fri, 14 Dec 2001, Perrin Harkins wrote:
I am planning to host an application and its size is going to be big one ,
so expect the concurrent number of connection s to be around 2200.
To combat the same , want to perform load sharing on 3-4 servers.
If you really expect 2200 concurrent connections, you should buy dedicated
load-balancing hardware like Big/IP or Cisco LocalDirector.
- Perrin
RE: load balancing on apache
Well, Linux Virtual Server is using ipchains (on the load balancer), and you can use any kind of OS on your real servers (those running your application), since it's only TCP/IP routing and/or forwarding. Thanks Frederic, I had only ever hand-cranked this kind of setup manually with ipchains and not looked as LVS. 8-) Yes indeed, the OS you run it on is Linux as a load-balancing router, and yes, the balanced machines can be anything. I've run various Windoze machines (ulp!) behind this kind of setup. Kind regards Derek. --Derek Jones 1051, Bollinger Road,Tel: 717 359 8817 Littlestown,Mobile: 717 977 4556 PA, 17340, USAEmail: [EMAIL PROTECTED]AIM: scunacc
Re: load balancing on apache
Aside from the fact I _really_ wouldn't expect that manny actual, live TCP connections at one time... Nor would I, although we did see huge numbers of open connections during peak times at eToys. Mostly to the image serving machines though. I _really_ hate so-called dedicated boxes. They're closed, nasty, inflexible and often don't work in _your_ situation. Doing smart session-based redirection can be hard with these boxes. You can make it work with homegrown solutions, but I've found the dedicated load-balancing tools (at least Big/IP) to be effective and fairly easy to work with, even with large loads, failover requirements, and more exotic stuff like sticky sessions. This is one area where the problem seems to be well enough defined for most people to use an off-the-shelf solution. They're often more expensive than they should be, but if you don't have someone on hand who knows the ipchains or LVS stuff it can save you some time and trouble. - Perrin
libapreq. Apache::Cookie returns different 'expires' than CGI::Cookie?
Hello, All! I wonder why my '$cookie-expires' for this code returns a different result than the similar one with CGI::Cookie (commented). The result is different in a way that some additional binary code is being added to the expiry date. $cookie = Apache::Cookie-new( $r, -name=access, -value=$value, -expires=+10m ); #my $cookie = new CGI::Cookie( -name=access, -value=$value, -expires=+10m ); $expiry = $cookie-expires; Any suggestions? Cheers, Alexei mailto:[EMAIL PROTECTED]
Re: load balancing on apache
[EMAIL PROTECTED] wrote: You can make it work with homegrown solutions, but I've found the dedicated load-balancing tools (at least Big/IP) to be effective and fairly easy to work with, even with large loads, failover requirements, and more exotic stuff like sticky sessions. This is one area where the problem seems to be well enough defined for most people to use an off-the-shelf solution. They're often more expensive than they should be, but if you don't have someone on hand who knows the ipchains or LVS stuff it can save you some time and trouble. - Perrin If I'm not mistaken didn't the article about perl/mod_perl and etoys have some interesting things regarding load balancing? http://www.perl.com/pub/a/2001/10/17/etoys.html
Re: ASP.NET Linux equivalent?
Thanks, Mark. I have looked at dotgnu, but they don't provide specifically what I was looking for - web GUI generation and automatic hookup to a database. So far, www.dbforms.org is the best product I found. Simon Mark Harrop wrote: A bit late, but.. Can't remember the exact URL, but search GOOGLE for GNUDOTNET. They have started to whip up a FREE version of MS's .net platform. Don't know if this is what you want, but. Cheers! Mark Harrop [EMAIL PROTECTED] `\|||/ (@@) ooO_(_)_Ooo___ _|_|_|_|_|_|_| Epping, Melbourne, Victoria, AUSTRALIA. - Original Message - From: Vsevolod Ilyushchenko [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, December 04, 2001 10:55 AM Subject: ASP.NET Linux equivalent? | Hi, | | Is anyone aware of a Linux product equivalent to ASP.NET from MS? Its most -- Simon (Vsevolod ILyushchenko) [EMAIL PROTECTED] http://www.simonf.com [EMAIL PROTECTED] A man who feels himself a citizen of the world whose loyalty is to the human race and to life, rather than to any exclusive part of it; a man who loves his country because he loves mankind, and whose judgement is not warped by tribal loyalties. Erich Fromm
Re: load balancing on apache
On Fri, 14 Dec 2001, Perrin Harkins wrote: I _really_ hate so-called dedicated boxes. They're closed, nasty, inflexible and often don't work in _your_ situation. Doing smart session-based redirection can be hard with these boxes. You can make it work with homegrown solutions, but I've found the dedicated load-balancing tools (at least Big/IP) to be effective and fairly easy to work with, even with large loads, failover requirements, and more exotic stuff like sticky sessions. This is one area where the problem seems to be well enough defined for most people to use an off-the-shelf solution. They're often more expensive than they should be, but if you don't have someone on hand who knows the ipchains or LVS stuff it can save you some time and trouble. I couldn't agree more. In terms of managability and scalability, the various software solutions simply add complexity to something that is already so. I've got some experience with Alteon AceDirectors and even though they seem little flakey at times, you do end up with true load balacing. (We have Cisco's solution deployed and they periodically have issues too.) DNS round-robin should be avoided at all costs. It's half-assed at best. In the case of a failure those clients that have that IP cached are SOL. On some of the systems that I've deployed we have a frontend proxy on the same box as the mod_perl with the mod_perl server listening on 127.0.0.1. This is behind an Alteon (or 2). You can put the proxy on a separate box as well but (I've seen some odd problems with TCP connections not working in this situation which I never fully understood but may have had to do with the Alteon being flakey.) Anyway, my advice is to go with a hardware load balancer/intelligent IP switch. In the long term, it will pay for itself in the time recovered from *not* being spent on troubleshooting complex problems. --Jeff -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin, Historical Review of Pennsylvania, 1759.
Re: libapreq. Apache::Cookie returns different 'expires' than CGI::Cookie?
Alexei Danchenkov [EMAIL PROTECTED] said something to this effect on 12/14/2001: Hello, All! I wonder why my '$cookie-expires' for this code returns a different result than the similar one with CGI::Cookie (commented). The result is different in a way that some additional binary code is being added to the expiry date. $cookie = Apache::Cookie-new( $r, -name=access, -value=$value, -expires=+10m ); #my $cookie = new CGI::Cookie( -name=access, -value=$value, -expires=+10m ); $expiry = $cookie-expires; Any suggestions? Maybe I'm just slow, but I can see the difference between the two. Can you elaborate? (darren) -- Blore's Razor: Given a choice between two theories, take the one which is funnier.
Re: load balancing on apache
At least one person MUST mention Backhand! www.backhand.org I'm working on a project right now that is expected to grow to 100+ servers in the next 12 months. In past projects I've worked on, handling of the log files becomes non-trivial at numbers far below that, so I built the new system to log via Spread (www.spread.org) and it is a wonderful thing to behold. When you start building really big systems, the insignificant things become big things, and the big things become huge! :-) On a side note: we originally used mod_log_spread to log via Spread, but found it to be a fairly nasty solution (lots of errors in the log files, otherwise worked OK) so we instead used good old mod_log_config and piped the output to a Perl program that spreads the logs. -- -- Tom Mornini -- InfoMania Printing Prepress
Re: load balancing on apache
Jeff Beard wrote: On Fri, 14 Dec 2001, Perrin Harkins wrote: I _really_ hate so-called dedicated boxes. They're closed, nasty, inflexible and often don't work in _your_ situation. Doing smart session-based redirection can be hard with these boxes. You can make it work with homegrown solutions, but I've found the dedicated load-balancing tools (at least Big/IP) to be effective and fairly easy to work with, even with large loads, failover requirements, and more exotic stuff like sticky sessions. This is one area where the problem seems to be well enough defined for most people to use an off-the-shelf solution. They're often more expensive than they should be, but if you don't have someone on hand who knows the ipchains or LVS stuff it can save you some time and trouble. I couldn't agree more. In terms of managability and scalability, the various software solutions simply add complexity to something that is already so. I've got some experience with Alteon AceDirectors and even though they seem little flakey at times, you do end up with true load balacing. (We have Cisco's solution deployed and they periodically have issues too.) DNS round-robin should be avoided at all costs. It's half-assed at best. In the case of a failure those clients that have that IP cached are SOL. On some of the systems that I've deployed we have a frontend proxy on the same box as the mod_perl with the mod_perl server listening on 127.0.0.1. This is behind an Alteon (or 2). You can put the proxy on a separate box as well but (I've seen some odd problems with TCP connections not working in this situation which I never fully understood but may have had to do with the Alteon being flakey.) Anyway, my advice is to go with a hardware load balancer/intelligent IP switch. In the long term, it will pay for itself in the time recovered from *not* being spent on troubleshooting complex problems. yes. It's a money vs. time/knowledge thing. Plus the state of the free software available. Anyone care to compare the features and power of some of the opensource projects vs. the Big/IP's? Which are the more promising opensource projects in this area? It would be nice to use an open source solution, or at least be able to offer it as an option, and I'd like to track the progress of some of the more promising projects. Ed Ed
mod_perl vs. C for high performance Apache modules
Hi All, Recently I did a substantial project for a client in using mod_perl. That client is happy with the work, but an investor with their company is very angry because of what a horrible choice mod_perl is for high-load web applications compared with Apache modules and even CGI programs, written in C. If anyone on this list could forward any resources that do comparisons along these lines, or even analysis of mod_perl's handling of high-load web traffic, I would be very grateful. Cheers, Jeff -- Jeff Yoak 626-705-6996
RE: mod_perl vs. C for high performance Apache modules
http://www.perl.com/pub/a/2001/10/17/etoys.html Yea, mod_perl really sucks ; ) I have even worked on poorly architectured and coded sites which still performed fairly well. Recently I did a substantial project for a client in using mod_perl. That client is happy with the work, but an investor with their company is very angry because of what a horrible choice mod_perl is for high-load web applications compared with Apache modules and even CGI programs, written in C. If anyone on this list could forward any resources that do comparisons along these lines, or even analysis of mod_perl's handling of high-load web traffic, I would be very grateful.
Re: mod_perl vs. C for high performance Apache modules
On Fri, Dec 14, 2001 at 12:12:09PM -0800, Jeff Yoak wrote: Hi All, Recently I did a substantial project for a client in using mod_perl. That client is happy with the work, but an investor with their company is very angry because of what a horrible choice mod_perl is for high-load web applications compared with Apache modules and even CGI programs, written in C. If anyone on this list could forward any resources that do comparisons along these lines, or even analysis of mod_perl's handling of high-load web traffic, I would be very grateful. CGI programs (even written in C) are very likely to be a lot slower than mod_perl handlers so I can't see where he gets that argument from. Does he really know what mod_perl is? The key to mod_perl development is speed, there are numerous testimonials from users implementing a lot of work in a very short time with mod_perl. Ask the clients investor wheter he wants to pay for having everything you did rewritten as an Apache module in C. That is very likely going to take a lot of time. Take a look at Joshua Chamas benchmarks (Although they're only hello world style apps) it shows that mod_perl is pretty fast. my $cent = 2; -- Thomas Eibner http://thomas.eibner.dk/ DnsZone http://dnszone.org/ mod_pointer http://stderr.net/mod_pointer
Re: mod_perl vs. C for high performance Apache modules
Investors suck like that. I have had to fight many of these battles. The first thing to do is find out specifically _why_ the investor thinks that so you can counter their claims. Trying to counter vague notions of 'terrible' is impossible. The opponent has to commit to an opinion before you can fight it. Then just point to many of the well-known sites on the success pages that are high volume and do quite well with mod_perl Explain that to do this project in Java or C or CGI would have costed more, taken longer and given negligible benefits. Thats what I do. I usually also show how my architecture can interact with other architectures via XML or directly at teh data store level. Good luck J On Friday, December 14, 2001, at 12:12 PM, Jeff Yoak wrote: Hi All, Recently I did a substantial project for a client in using mod_perl. That client is happy with the work, but an investor with their company is very angry because of what a horrible choice mod_perl is for high-load web applications compared with Apache modules and even CGI programs, written in C. If anyone on this list could forward any resources that do comparisons along these lines, or even analysis of mod_perl's handling of high-load web traffic, I would be very grateful. Cheers, Jeff -- Jeff Yoak 626-705-6996
Re: Comparison of different caching schemes
I was using Cache::SharedMemoryCache on my system. I figured, Hey, it's RAM, right? It's gonna be WAY faster than anything disk-based. The thing you were missing is that on an OS with an aggressively caching filesystem (like Linux), frequently read files will end up cached in RAM anyway. The kernel can usually do a better job of managing an efficient cache than your program can. For what it's worth, DeWitt Clinton accompanied his first release of File::Cache (the precursor to Cache::FileCache) with a benchmark showing this same thing. That was the reason File::Cache was created. And ++ on Paul's comments about Devel::DProf and other profilers. - Perrin
Re: mod_perl vs. C for high performance Apache modules
Jeff Yoak [EMAIL PROTECTED] writes: Hi All, Recently I did a substantial project for a client in using mod_perl. That client is happy with the work, but an investor with their company is very angry because of what a horrible choice mod_perl is for high-load web applications compared with Apache modules and even CGI programs, written in C. If anyone on this list could forward any resources that do comparisons along these lines, or even analysis of mod_perl's handling of high-load web traffic, I would be very grateful. Kill the investors. Really. -- David Hodgkinson, Wizard for Hirehttp://www.davehodgkinson.com Editor-in-chief, The Highway Star http://www.deep-purple.com Deep Purple Family Tree news http://www.slashrock.com Interim Technical Director, Web Architecture Consultant for hire
RE: mod_perl vs. C for high performance Apache modules
I spoke to the technical lead at Yahoo who said mod_perl will not scale as well as c++ when you get to their level of traffic, but for a large ecommerce site mod_perl is fine. I think people just stick to what they started with. We wrote our site racesearch.com using mod_perl and it is super fast. (faster than Amazon.com) -tom -Original Message- From: Jeff Yoak [mailto:[EMAIL PROTECTED]] Sent: Friday, December 14, 2001 12:12 PM To: [EMAIL PROTECTED] Subject: mod_perl vs. C for high performance Apache modules Hi All, Recently I did a substantial project for a client in using mod_perl. That client is happy with the work, but an investor with their company is very angry because of what a horrible choice mod_perl is for high-load web applications compared with Apache modules and even CGI programs, written in C. If anyone on this list could forward any resources that do comparisons along these lines, or even analysis of mod_perl's handling of high-load web traffic, I would be very grateful. Cheers, Jeff -- Jeff Yoak 626-705-6996
RE: mod_perl vs. C for high performance Apache modules
I spoke to the technical lead at Yahoo who said mod_perl will not scale as well as c++ when you get to their level of traffic, but for a large ecommerce site mod_perl is fine. Scalability has less to do with language/execution environment than which database you are using. Path length is affected by language, but that's usually not the major factor in scalability. You want short path lengths to get more efficiency out of your machines. Rob
RE: Comparison of different caching schemes
Another powerful tool for tracking down performance problems is perl's
profiler combined with Devel::DProf and Apache::DProf. Devel::DProf
is bundled with perl. Apache::DProf is hidden in the Apache-DB package
on CPAN.
Ya know the place in my original comment where I was optimizing a different
subsystem? I just discovered Devel::DProf last week (after 5 *years* of
perl... smacks forehead), and was using that. *AND* had improved a sore
spot's performance by 10% without even working hard, because of profiling.
Point taken.
At the same time I added some code to track the time it takes to
process a request using Time::HiRes. This value is set as a note via
$r-note('REQTIME'). A customlog directive takes care of dumping that
value in the logs...
Hmm... I was already logging a status message via warn(), I did the SAME
TRICK but stored it in a local variable because I didn't need to go as far
as a customlog...
Sounds like great minds think alike! :-)
L8r,
Rob
#!/usr/bin/perl -w
use Disclaimer qw/:standard/;
Re: mod_perl vs. C for high performance Apache modules
I spoke to the technical lead at Yahoo who said mod_perl will not scale as well as c++ when you get to their level of traffic, but for a large ecommerce site mod_perl is fine. According to something I once read by David Filo, Yahoo also had to tweak the FreeBSD code because they had trouble scaling *TCP/IP*! I would say their experience is not typical. - Perrin
Re: mod_perl vs. C for high performance Apache modules
Perrin Harkins [EMAIL PROTECTED] writes: I spoke to the technical lead at Yahoo who said mod_perl will not scale as well as c++ when you get to their level of traffic, but for a large ecommerce site mod_perl is fine. According to something I once read by David Filo, Yahoo also had to tweak the FreeBSD code because they had trouble scaling *TCP/IP*! I would say their experience is not typical. Increasing the number of file handles, I'd wager. That was an issue on 2.x linux kernels too. -- David Hodgkinson, Wizard for Hirehttp://www.davehodgkinson.com Editor-in-chief, The Highway Star http://www.deep-purple.com Deep Purple Family Tree news http://www.slashrock.com Interim Technical Director, Web Architecture Consultant for hire
Re: mod_perl vs. C for high performance Apache modules
At 09:15 PM 12/14/2001 +0100, Thomas Eibner wrote: The key to mod_perl development is speed, there are numerous testimonials from users implementing a lot of work in a very short time with mod_perl. Ask the clients investor wheter he wants to pay for having everything you did rewritten as an Apache module in C. That is very likely going to take a lot of time. Thank you for your reply. I realized in reading it that my tone leads one to the common image of a buzzword driven doody-head who wants this because of what he read in Byte. That's certainly common enough, and I've never had a problem dealing with such types. (Well... not an unsolvable problem... :-) This is something different. The investor is in a related business, and has developed substantially similar software for years. And it is really good. What's worse is that my normal, biggest argument isn't compelling in this case, that by the time this would be done in C, I'd be doing contract work on Mars. The investor claims to have evaluated Perl vs. C years ago, to have witnessed that every single hit on the webserver under mod_perl causes a CPU usage spike that isn't seen with C, and that under heavy load mod_perl completely falls apart where C doesn't. (This code is, of course, LONG gone so I can't evaluate it for whether the C was good and the Perl was screwy.) At any rate, because of this, he's spent years having good stuff written in C. Unbeknownst to either me or my client, both this software and its developer were available to us, so in this case it would have been faster, cheaper and honestly even better, by which I mean more fully-featured. So he's upset. Everyone acknowledges that given our particular circumstances, it would have been better to build upon what we already had, but because of his previous experience he feels that mod_perl wasn't even a responsible choice even within the limits of our lack of knowledge of his software and its availability. So I'm trying to show that mod_perl doesn't suck, and that it is, in fact, a reasonable choice. Though within these limits it is still reasonable to point out the development cycle, emotionally it is the least compelling form of argument, because the investor has a hard time removing from consideration that given our particular situation, there was a very fast solution in using his C-based routines. Take a look at Joshua Chamas benchmarks (Although they're only hello world style apps) it shows that mod_perl is pretty fast. I will look for this particularly. Thanks. Cheers, Jeff -- Jeff Yoak 626-705-6996
Re: mod_perl vs. C for high performance Apache modules
At 03:12 PM 12/14/01, Jeff Yoak wrote: Recently I did a substantial project for a client in using mod_perl. That client is happy with the work, but an investor with their company is very angry because of what a horrible choice mod_perl is for high-load web applications compared with Apache modules and even CGI programs, written in C. If anyone on this list could forward any resources that do comparisons along these lines, or even analysis of mod_perl's handling of high-load web traffic, I would be very grateful. How about the myths page? http://perl.apache.org/perl_myth.html Todd
Re: Comparison of different caching schemes
On Fri, 14 Dec 2001, Perrin Harkins wrote: The thing you were missing is that on an OS with an aggressively caching filesystem (like Linux), frequently read files will end up cached in RAM anyway. The kernel can usually do a better job of managing an efficient cache than your program can. Plus for some reason IPC overhead seems to seriously degrade as the size of the overall shared memory segment increases. I'm not sure why this is but I think the docs for IPC::Shareable mention this. Maybe for _very_ small amounts of data, shared memory might still be a win. -dave /*== www.urth.org We await the New Sun ==*/
RE: mod_perl vs. C for high performance Apache modules
On Fri, 14 Dec 2001, Thomas Moore wrote: I spoke to the technical lead at Yahoo who said mod_perl will not scale as well as c++ when you get to their level of traffic, but for a large ecommerce site mod_perl is fine. Well, Yahoo is _extremely_ atypical. And they do a lot of stuff that involves custom coded Apache modules (in C, I think, not C++, though maybe both). Amazon reportedly uses a similar approach. Jeremy Zawodny is a frequent contributor on the MySQL list and a Perl guy so if you're really curious you could probably email him a polite question for more details. He's a nice guy. -dave /*== www.urth.org We await the New Sun ==*/
Re: mod_perl vs. C for high performance Apache modules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Dec 14, 2001 at 12:12:09PM -0800, Jeff Yoak wrote: Recently I did a substantial project for a client in using mod_perl. That client is happy with the work, but an investor with their company is very angry because of what a horrible choice mod_perl is for high-load web applications compared with Apache modules and even CGI programs, written in C. Word of the day: ultracrepidarianism Of course, financial investors are experts in the field of backend systems. One in this situation wishes your client would pick up on that. The fact that he's comparing mod_perl (an Apache module) to an Apache module should be a glaring sign of said investor's utter cluelessness. The fact that he's even mentioning CGI versus a server API-level module -- well, I'll stop now before I embarass someone. If anyone on this list could forward any resources that do comparisons along these lines, or even analysis of mod_perl's handling of high-load web traffic, I would be very grateful. Whether C is more efficient than a RAD language like Perl (or Python or PHP) is an incredibly stupid question, because one with sufficient knowledge should know already that the answer is yes. The real question is whether said efficiency is worth the arduous hassle of building the app in C. Considering the speed at which modern servers execute interpreted or JIT-compiled languages, that answer is almost always no. There is fast, but then there's fast enough (and finished developing in 25% of the time). They'll have to decide what's more important. Now, as for case studies, here's a quick list: http://perl.apache.org/sites.html And then this article, outlining how mod_perl was used to build the eToys site: http://www.perl.com/pub/a/2001/10/17/etoys.html And now for a completely shameless plug: http://www.iqcoordinator.com/ Which is a processing-intensive work order management system, built entirely on mod_perl. (Some day I will write an article myself :) Our systems don't even break a sweat. Actually, mod_perl saved us from having to buy more hardware. It's plenty fast. - -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer, IQ Coordinator Project Lead The IQ Group, Inc. http://www.theiqgroup.com/ -BEGIN PGP SIGNATURE- Version: PGP 6.5.8 iQA/AwUBPBpphQOGqGs0PadnEQLW2gCdGonCCAU0aCauPTTsIZMvzcWU1mIAnj3J BBNeCw2RdSN90qTCYDFLUYPP =Exa7 -END PGP SIGNATURE-
Re: mod_perl vs. C for high performance Apache modules
I dont think its your responsibility anymore. If the investor had a preference he should have stated it BEFORE work began. If your client did not keep him informed then your client has that burden to bear. You did your job, the client likes what you did, it works. Let them fight the political battle. Comparing mod_perl 'years ago' is totally irrelevant. Modperl has grown up so much since 'years ago' that its not even funny. J- On Friday, December 14, 2001, at 12:58 PM, Jeff Yoak wrote: At 09:15 PM 12/14/2001 +0100, Thomas Eibner wrote: The key to mod_perl development is speed, there are numerous testimonials from users implementing a lot of work in a very short time with mod_perl. Ask the clients investor wheter he wants to pay for having everything you did rewritten as an Apache module in C. That is very likely going to take a lot of time. Thank you for your reply. I realized in reading it that my tone leads one to the common image of a buzzword driven doody-head who wants this because of what he read in Byte. That's certainly common enough, and I've never had a problem dealing with such types. (Well... not an unsolvable problem... :-) This is something different. The investor is in a related business, and has developed substantially similar software for years. And it is really good. What's worse is that my normal, biggest argument isn't compelling in this case, that by the time this would be done in C, I'd be doing contract work on Mars. The investor claims to have evaluated Perl vs. C years ago, to have witnessed that every single hit on the webserver under mod_perl causes a CPU usage spike that isn't seen with C, and that under heavy load mod_perl completely falls apart where C doesn't. (This code is, of course, LONG gone so I can't evaluate it for whether the C was good and the Perl was screwy.) At any rate, because of this, he's spent years having good stuff written in C. Unbeknownst to either me or my client, both this software and its developer were available to us, so in this case it would have been faster, cheaper and honestly even better, by which I mean more fully-featured. So he's upset. Everyone acknowledges that given our particular circumstances, it would have been better to build upon what we already had, but because of his previous experience he feels that mod_perl wasn't even a responsible choice even within the limits of our lack of knowledge of his software and its availability. So I'm trying to show that mod_perl doesn't suck, and that it is, in fact, a reasonable choice. Though within these limits it is still reasonable to point out the development cycle, emotionally it is the least compelling form of argument, because the investor has a hard time removing from consideration that given our particular situation, there was a very fast solution in using his C-based routines. Take a look at Joshua Chamas benchmarks (Although they're only hello world style apps) it shows that mod_perl is pretty fast. I will look for this particularly. Thanks. Cheers, Jeff -- Jeff Yoak 626-705-6996
RE: mod_perl vs. C for high performance Apache modules
Mod_perl doesn't suck, and it certainly doesn't have a huge hit on the CPU. (of course it all depends what you're doing, but for the most part it's small) Having used many high level web development environments, from C to Java to TCL and perl, I find mod_perl at the top end of the scalability scale. Plenty of fast and heavily loaded sites use mod_perl without throwing tonnes of hardware at it, AND as a side bonus, chances are the development time was faster than writing in almost anyything else. I run a wee little web site, it runs on 4 servers (1 static server, 2 mysql servers, and one mod_perl server) all told, this hardware cost about $10k usd. Yesterday, the site served 2,000,000 page loads (ads, impressions, how every you count it), with about 6 Million requests to the mod_perl server, which in turn passed on about 200 Million requests to the DB server. Yes, I struggle with performance, but under most other development environments I'd have been up against the wall a long time ago. Mod_perl is NOT CPU intensive. It IS memory intensive. Due to the architecture of apache, and the memory overhead some care must be taken when planning a large capacity site, but fortunately all of this is nicely documented in the guide. There are other solutions. Yes, I suppose I could rewrite large parts of the site in C. It certainly wouldn't help with development (which is always patching this, adding feature Z), it might, maybe reduce some of the memory overhead. My largest challenge has actually been to get mysql (written in C) to properly handle it's share of the workload. Take a perusal at the Stories section on perl.apache.org http://perl.apache.org/stories/ ValueClick serves an incredible number of impressions via their mod_perl systems. It scales, it's fast, and it doesn't take a lot of hardware. --A -Original Message- From: Jeff Yoak [mailto:[EMAIL PROTECTED]] This is something different. The investor is in a related business, and has developed substantially similar software for years. And it is really good. What's worse is that my normal, biggest argument isn't compelling in this case, that by the time this would be done in C, I'd be doing contract work on Mars. The investor claims to have evaluated Perl vs. C years ago, to have witnessed that every single hit on the webserver under mod_perl causes a CPU usage spike that isn't seen with C, and that under heavy load mod_perl completely falls apart where C doesn't. (This code is, of course, LONG gone so I can't evaluate it for whether the C was good and the Perl was screwy.) At any rate, because of this, he's spent years having good stuff written in C. Unbeknownst to either me or my client, both this software and its developer were available to us, so in this case it would have been faster, cheaper and honestly even better, by which I mean more fully-featured. So he's upset. Everyone acknowledges that given our particular circumstances, it would have been better to build upon what we already had, but because of his previous experience he feels that mod_perl wasn't even a responsible choice even within the limits of our lack of knowledge of his software and its availability. So I'm trying to show that mod_perl doesn't suck, and that it is, in fact, a reasonable choice. Though within these limits it is still reasonable to point out the development cycle, emotionally it is the least compelling form of argument, because the investor has a hard time removing from consideration that given our particular situation, there was a very fast solution in using his C-based routines.
Re: mod_perl vs. C for high performance Apache modules
On Fri, Dec 14, 2001 at 12:58:51PM -0800, Jeff Yoak wrote: At 09:15 PM 12/14/2001 +0100, Thomas Eibner wrote: The key to mod_perl development is speed, there are numerous testimonials from users implementing a lot of work in a very short time with mod_perl. Ask the clients investor wheter he wants to pay for having everything you did rewritten as an Apache module in C. That is very likely going to take a lot of time. Thank you for your reply. I realized in reading it that my tone leads one to the common image of a buzzword driven doody-head who wants this because of what he read in Byte. That's certainly common enough, and I've never had a problem dealing with such types. (Well... not an unsolvable problem... :-) True, it sounded a bit like that. This is something different. The investor is in a related business, and has developed substantially similar software for years. And it is really good. What's worse is that my normal, biggest argument isn't compelling in this case, that by the time this would be done in C, I'd be doing contract work on Mars. The investor claims to have evaluated Perl vs. C years ago, to have witnessed that every single hit on the webserver under mod_perl causes a CPU usage spike that isn't seen with C, and that under heavy load mod_perl completely falls apart where C doesn't. (This code is, of course, LONG gone so I can't evaluate it for whether the C was good and the Perl was screwy.) At any rate, because of this, he's spent years having good stuff written in C. Unbeknownst to either me or my client, both this software and its developer were available to us, so in this case it would have been faster, cheaper and honestly even better, by which I mean more fully-featured. I'm wondering where the investor have been hiding if he isn't telling you this until now. It's hard to pull on resources that you have no idea are available to you. If he did the comparision years ago he should be doing his tests over again, since a lot of things have happened over the last few years. From what you write it seems to me that he can't just be using plain CGI in C, since it still has the fork overhead that mod_perl doesn't and even a small hello world test would prove that mod_perl is faster there (I didn't try it, but I'm sure we could make some tests). Although you haven't told us much about what the actual application you wrote for your client does, I must say that I've found it more error prone and time-consuming doing any database stuff in C. I'm not a C programmer of heart, but I have done a fair amount of programming with it and it certainly hasn't been as fast to develop as applications relying on DBI. You haven't told us what you normally program in either, so we don't know if you do mod_perl most of the time or you just write your stuff in C regulary, this could also have an impact on the length of the project in the end. So he's upset. Everyone acknowledges that given our particular circumstances, it would have been better to build upon what we already had, but because of his previous experience he feels that mod_perl wasn't even a responsible choice even within the limits of our lack of knowledge of his software and its availability. To me it seems like he should be upset with himself. If he knows he has some good tools he should have told your client way before this project even started anyway. So I'm trying to show that mod_perl doesn't suck, and that it is, in fact, a reasonable choice. Though within these limits it is still reasonable to point out the development cycle, emotionally it is the least compelling form of argument, because the investor has a hard time removing from consideration that given our particular situation, there was a very fast solution in using his C-based routines. I certainly hope that you find something that will show him that mod_perl isn't a bad choice. -- Thomas Eibner http://thomas.eibner.dk/ DnsZone http://dnszone.org/ mod_pointer http://stderr.net/mod_pointer
Re: mod_perl vs. C for high performance Apache modules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Dec 14, 2001 at 12:58:51PM -0800, Jeff Yoak wrote: This is something different. The investor is in a related business, and has developed substantially similar software for years. And it is really good. What's worse is that my normal, biggest argument isn't compelling in this case, that by the time this would be done in C, I'd be doing contract work on Mars. The investor claims to have evaluated Perl vs. C years ago, to have witnessed that every single hit on the webserver under mod_perl causes a CPU usage spike that isn't seen with C, and that under heavy load mod_perl completely falls apart where C doesn't. (This code is, of course, LONG gone so I can't evaluate it for whether the C was good and the Perl was screwy.) At any rate, because of this, he's spent years having good stuff written in C. Unbeknownst to either me or my client, both this software and its developer were available to us, so in this case it would have been faster, cheaper and honestly even better, by which I mean more fully-featured. Ah, the good old my timeless knowledge from the Nixon administration still applies argument. Remember that the speed of both languages has increased geometrically as a function of hardware speed. 5 years ago you may have been talking a difference of a second or two between Perl and C. Nowadays you'll be measuring the differences in milliseconds, if that much. And you're right, one still can't verify the veracity of the ancient benchmarked code. On another list someone was dealing with Perl and DBI against PHP for a database-driven site, with nothing to go on but some ApacheBench numbers showing the PHP page about six orders of magnitude faster. Then one minor difference of note: the Perl program had output about 70MB of data; the PHP program, about 940 bytes. I assume that the PHP program was doing a null loop or something where the query should have been. Get him to do a real unbiased comparison on modern hardware, and then defy him to claim that the milliseconds he saves are worth the effort. - -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer, IQ Coordinator Project Lead The IQ Group, Inc. http://www.theiqgroup.com/ -BEGIN PGP SIGNATURE- Version: PGP 6.5.8 iQA/AwUBPBpsFQOGqGs0PadnEQJ9TgCgtZnIhFLq/L/DeZA5CS4yAjzBRiEAn3ED lTRl2/yaG9eH7BK785GKajp3 =jLX5 -END PGP SIGNATURE-
Re: mod_perl vs. C for high performance Apache modules
Hi there, On Fri, 14 Dec 2001, Jeff Yoak wrote: This is something different. [big snip] Indeed it is. It's a refreshingly honest appraisal of what might, in hindsight, have been easily avoided mistakes. And nobody ever did anything without making a few. Thanks. 73, Ged. PS: Are any of those C routines available Open Source? :)
Re: mod_perl vs. C for high performance Apache modules
At 03:58 PM 12/14/2001, Jeff Yoak wrote: At 09:15 PM 12/14/2001 +0100, Thomas Eibner wrote: The key to mod_perl development is speed, there are numerous testimonials from users implementing a lot of work in a very short time with mod_perl. Ask the clients investor wheter he wants to pay for having everything you did rewritten as an Apache module in C. That is very likely going to take a lot of time. Thank you for your reply. I realized in reading it that my tone leads one to the common image of a buzzword driven doody-head who wants this because of what he read in Byte. That's certainly common enough, and I've never had a problem dealing with such types. (Well... not an unsolvable problem... :-) This is something different. The investor is in a related business, and has developed substantially similar software for years. And it is really good. What's worse is that my normal, biggest argument isn't compelling in this case, that by the time this would be done in C, I'd be doing contract work on Mars. The investor claims to have evaluated Perl vs. C years ago, to have witnessed that every single hit on the webserver under mod_perl causes a CPU usage spike that isn't seen with C, and that under heavy load mod_perl completely falls apart where C doesn't. (This code is, of course, LONG gone so I can't evaluate it for whether the C was good and the Perl was screwy.) At any rate, because of this, he's spent years having good stuff written in C. Unbeknownst to either me or my client, both this software and its developer were available to us, so in this case it would have been faster, cheaper and honestly even better, by which I mean more fully-featured. CPU usage is certainly one factor... but CPUs are cheap compared to development man-hours. Since you haven't provided any details on the application, this may not be relevant, but most of the web apps that we write (and I read about here) spend much of their time waiting for responses from other back-end servers - databases, NFS mounted file systems, or whatever. It's probably undeniable that a well written C application will run faster than almost anything in an interpreted language, but that may not make much of a difference to the total response time. -Simon Simon Rosenthal ([EMAIL PROTECTED]) Web Systems Architect Northern Light Technology One Athenaeum Street. Suite 1700, Cambridge, MA 02142 Phone: (617)621-5296: URL: http://www.northernlight.com Northern Light - Just what you've been searching for
Re: mod_perl vs. C for high performance Apache modules
So I'm trying to show that mod_perl doesn't suck, and that it is, in fact, a reasonable choice. Though within these limits it is still reasonable to point out the development cycle, emotionally it is the least compelling form of argument, because the investor has a hard time removing from consideration that given our particular situation, there was a very fast solution in using his C-based routines. Well, that is the primary reason for using Perl over C, and you really have to count maintenance and the relative likelihood of C-ish bugs like buffer overflows as part of it. Well-coded C should be faster than Perl, but Perl is fast enough for nearly any web-based application. If this guy saw CPU spikes, he probably had something else wrong, like running out of memory. You might find this article aboout C and Perl performance useful: http://www.perl.com/pub/a/2001/06/27/ctoperl.html - Perrin
Re: mod_perl vs. C for high performance Apache modules
... years ago ... Are you even sure he evaluated mod_perl and not Perl CGI scripts?? Launching the interpreter and compiling every time might spike the CPU. Like others have said, you would really have to benchmark the mod_perl and Apache that you're using now; both have improved considerably over the years. You can point to the success stories others have mentioned to show that it really is one of the standard industry solutions that works well in many high-traffic situations. He's clearly arguing from outdated data and emotion. Also, if you delivered what you said you would deliver, that ought to be the end of it. If the site is performing according to expectations and promises, then he doesn't have any real basis to complain. If it would truly deliver tangible advantages to the client to rewrite it in C, or incorporate some of his C code in your work (Perl and C can get along sometimes), then you might consider giving him a quote to rewrite it. Ask him to put up or shut up. A gentler approach might be, Given we did what we did (and it works), what do you really want us to do now? What should happen from this point forward? If there isn't a constructive answer to that, then all you're dealing with is a temper tantrum. ---Wes Sheldahl ( father of four young'uns ) Jeff Yoak [EMAIL PROTECTED] on 12/14/2001 03:58:51 PM To: Thomas Eibner [EMAIL PROTECTED] cc: [EMAIL PROTECTED] (bcc: Wesley Sheldahl/Lex/Lexmark) Subject: Re: mod_perl vs. C for high performance Apache modules [snip] So he's upset. Everyone acknowledges that given our particular circumstances, it would have been better to build upon what we already had, but because of his previous experience he feels that mod_perl wasn't even a responsible choice even within the limits of our lack of knowledge of his software and its availability. [snip] Cheers, Jeff
Re: mod_perl vs. C for high performance Apache modules
All, I wasn't sure what volume of response to expect when I originally wrote. Thank you all for the comments that you all are making. They are helping. Given that the response is fairly high, I'm waiting for stuff to roll in rather than replying to each of you. Don't think it is falling on unappreciating ears. :-) To respond to a few recurring comments / questions: Me? I've spent most of the last four years working on mod_perl-based stuff and most of the last eight working with Perl. Actually I've worked with folks who were involved with some of the projects you've mentioned, having been at idealab!, a parent of eToys and CitySearch. One of the original (THE original?) developer at CitySearch was probably the most helpful mentor / teacher I've ever worked with. I programmed in C a lot early in my career, but at this point I couldn't write anything substantial without brushing up, and frankly wouldn't care to. It just isn't as fun to work with C. But then, the argument, But if you used C, you wouldn't get to work with ME! may not convince some of these people with their values all screwed up... ;-) The project? What I consider to be standard web junk. About 30% ecommerce combined with lots of database-driven, interactive content, some authentication foo and things like that. The thing is that it is in the adult industry and the investor in question turns on the hose... well... there will be lots of traffic. Mistakes and misunderstandings? Sure. And yes, as some of you have pointed out publicly or privately, not my fault. I was kept very insulated from the people who were familiar with the alternatives. My involvement at this point is to try to smooth things over and keep the project functional. These immediate problems aside, the people involved are great to work with and if everyone feels better about the situation and things move forward in the best possible way from here, there will be a lot of valuable work for me. So I'm trying to help. More than you cared to hear about and terribly off-topic for the list? Sure. But you did sorta ask, and somehow it seemed rude to not reply. Forgive me and thanks for providing all of your commentary. Cheers, Jeff -- Jeff Yoak 626-705-6996
Re: mod_perl vs. C for high performance Apache modules
Dave Hodgkinson wrote on Fri, Dec 14 2001 (20:54:22 +): Perrin Harkins [EMAIL PROTECTED] writes: According to something I once read by David Filo, Yahoo also had to tweak the FreeBSD code because they had trouble scaling *TCP/IP*! I would say their experience is not typical. Increasing the number of file handles, I'd wager. That was an issue on you really don't have to tweak any FreeBSD code for that, just do sysctl -w kern.maxfiles=10 and the file table will grow up to the new limit. 2.x linux kernels too. that was an issue with 2.0.x, since 2.2.x you can do it with echo 10 /proc/sys/fs/file-max cheers, -- Toni Andjelkovic [EMAIL PROTECTED]
Re: mod_perl vs. C for high performance Apache modules
Toni Andjelkovic [EMAIL PROTECTED] writes: 2.x linux kernels too. that was an issue with 2.0.x, since 2.2.x you can do it with That was what I meant...decimal point in the wrong place... :-) -- David Hodgkinson, Wizard for Hirehttp://www.davehodgkinson.com Editor-in-chief, The Highway Star http://www.deep-purple.com Deep Purple Family Tree news http://www.slashrock.com Interim Technical Director, Web Architecture Consultant for hire
LWP Help
Hi folks, Im running an apache/mod_perl server and hope this isn't too far
off base. I'm trying to get the following script to run against an
e-merchant system. I've narrowed it down to the content_type and am
struggling on how to send form data via LWP::UserAgent.
I beleive all I need is to disable the
$r-content_type('application/x-www-form-urlencoded'), but dont quite
understand how to do that. How many different content types are there and
is it possible to use the LWP object and somehow disable it?
use strict;
use LWP::UserAgent;
my $ua = new LWP::UserAgent;
$ua-agent(AgentName/0.1 . $ua-agent);
# Create a request
my $req = new HTTP::Request POST = $post;
$req-content_type('application/x-www-form-urlencoded');
$req-content(field1=$val1field2=$val2);
# Pass request to the user agent and get a response back
my $res = $ua-request($req);
my $response = $res-content;
print response:$response:\n;
#
Kirk
Re: Comparison of different caching schemes
So our solution was caching in-process with just a hash, and using a
DBI/mysql persistent store.
in pseudo code
sub get_stuff {
if (! $cache{$whatever} ) {
if !( $cache{whatever} = dbi_lookup()) {
$cache{$whatever}=derive_data_from_original_source($whatever);
dbi_save($cache_whatever);
}
}
$cache{$whatever}
}
That's actually a bit different. That would fail to notice updates between
processes until the in-memory cache was cleared. Still very useful for
read-only data or data that can be out of sync for some period though.
The filesystem based / time sensitive aging is a nice little thing we
should
put up in CPAN. We've just not done so yet.
How does it differ from the other solutions like Cache::FileCache? Is it
something you could add to an existing module?
- Perrin
RE: mod_perl vs. C for high performance Apache modules
On Fri, 14 Dec 2001, Thomas Moore wrote: I spoke to the technical lead at Yahoo who said mod_perl will not scale as well as c++ when you get to their level of traffic, but for a large ecommerce site mod_perl is fine. the old memory is cheap rationalization doesn't go over very well at that scale either, eh.
Re: mod_perl vs. C for high performance Apache modules
-- Jeff Yoak [EMAIL PROTECTED] on 12/14/01 12:58:51 -0800 This is something different. The investor is in a related business, and has developed substantially similar software for years. And it is really good. What's worse is that my normal, biggest argument isn't compelling in this case, that by the time this would be done in C, I'd be doing contract work on Mars. The investor claims to have evaluated Perl vs. C years ago, to have witnessed that every single hit on the webserver under mod_perl causes a CPU usage spike that isn't seen with C, and that under heavy load mod_perl completely falls apart where C doesn't. (This code is, of course, LONG gone so I can't evaluate it for whether the C was good and the Perl was screwy.) At any rate, because of this, he's spent years having good stuff written in C. Unbeknownst to either me or my client, both this software and its developer were available to us, so in this case it would have been faster, cheaper and honestly even better, by which I mean more fully-featured. Constructing the $r object in perl-space is an overhead that mod_perl causes. This overhead has been managed more effectively in recent versions of perl/mod_perl. A study done a few years ago probably involved machines with significantly less core and CPU horsepower than the average kiddie-games PC does today. Net result is that any overhead caused by mod_perl in the previous study may well have been either mitigated with better code or obviated by faster hardware [how's that for a sentence?]. Net result is that the objection is probably based on once- valid but now out of date analysis. -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 800 762 1582
Re: Comparison of different caching schemes
On December 14, 2001 03:04 pm, Perrin Harkins wrote:
So our solution was caching in-process with just a hash, and using a
DBI/mysql persistent store.
in pseudo code
sub get_stuff {
if (! $cache{$whatever} ) {
if !( $cache{whatever} = dbi_lookup()) {
$cache{$whatever}=derive_data_from_original_source($whatever);
dbi_save($cache_whatever);
}
}
$cache{$whatever}
}
That's actually a bit different. That would fail to notice updates between
processes until the in-memory cache was cleared. Still very useful for
read-only data or data that can be out of sync for some period though.
The filesystem based / time sensitive aging is a nice little thing we
should
put up in CPAN. We've just not done so yet.
How does it differ from the other solutions like Cache::FileCache? Is it
something you could add to an existing module?
Performance,and key structure, semantics. Its mostly different, not
better/worse.
=pod
=head1 NAME
UFMEDIA::CacheOneFile - cache a scalar value in a file on disk
=head1 SYNOPSIS
use UFMEDIA::CacheOneFile;
my $cache = new UFMEDIA::CacheOneFile(
cache_file = '/var/cache/myapp/flurge.cache',
max_age= 30,
refill_sub = sub { recalculate_flurges(31337, 'blue', 42) },
);
my $value = $cache-get_value;
=head1 DESCRIPTION
UFMEDIA::CacheOneFile enables you to cache a single scalar value in a file
on disk. Given a filename under a writable directory, a maximum age, and
a reference to a refill subroutine, a cache object will cache the result
of the refill subroutine in the file the first time Bget_value() is called,
and use the cached value for subsequent calls to Bget_value() until
Bmax_age the cach
e file is more than Bmax_age seconds old.
If multiple processes share a single cache file, the first process that
reads the cache file after it has expired will take responsibility for
replacing it with an up-to-date copy. Other processes needing up-to-date
information will wait for this to finish and will then use the new value.
=head1 AUTHOR
Mike Lyons [EMAIL PROTECTED]
=head1 SEE ALSO
perl(1).
=cut
- Perrin
--
Jay yohimbe Thorne [EMAIL PROTECTED]
Mgr Sys Tech, Userfriendly.org
Re: load balancing on apache
I think you also have to specify weather your web applications are state-less or not. If stateless, then you can just use DNS Round Robin technique or lbnamed (Load Balancing Name Server) to achieve this load balancing or high availability. If your apps are statefull as in ASP, Cold Fusion, JSP, etc, then you'll need to retain the sessions and that becomes more complicated but possible. On Fri, 14 Dec 2001, Hemant Singh wrote: Hi All I am planning to host an application and its size is going to be big one , so expect the concurrent number of connection s to be around 2200.To combat the same , want to perform load sharing on 3-4 servers.So the ide is to put one machine on external IP and this machine , after receiving the requests would forward them to any of the other three machines having the application deployed and running on the same environment.Pls suggest how can i achieve this on apache. Thanks in advance Hemant -- - Medi Montaseri [EMAIL PROTECTED] Unix Distributed Systems EngineerHTTP://www.CyberShell.com CyberShell Engineering -
Re: mod_perl vs. C for high performance Apache modules
So I'm trying to show that mod_perl doesn't suck, and that it is, in fact, a reasonable choice. I think one of the selling points for mod_perl is its extensibility: modules can be written in C. Depending on the C code you have access to, a good solution might be to try to wrap it into mod_perl modules. Tim
Re: Comparison of different caching schemes
At 6:04 PM -0500 12/14/01, Perrin Harkins wrote: That's actually a bit different. That would fail to notice updates between processes until the in-memory cache was cleared. Still very useful for read-only data or data that can be out of sync for some period though. The primary problem with everything mentioned thus far is that they are almost entirely based around the concept of a single server. Caching schemes that are both fast and work across multiple servers and process instances are very hard to find. After reading the eToys article, I decided that BerkeleyDB was worth a look. We discovered that it was very fast and would make a great cache for some of our commonly used database queries. The problem was that we are running on 5 different servers, load balanced by Big/IP. Again, taking my que from the eToys article, I began working on a data exchange system (using perl instead of C) which multicasts data packets to the listening servers. So far, our only problems have been with the deadlocking (solved with db_deadlock), and a few corrupt records. I'm considering uploading to CPAN the stuff I've written for the caching, but haven't had the time to make it generic enough. I also haven't performed any benchmarks other than the Wow, that's a lot faster benchmark. One limitation to the stuff I've written is that the daemons (listeners) are non threaded, non forking. That and it's all based on UDP. Rob -- When I used a Mac, they laughed because I had no command prompt. When I used Linux, they laughed because I had no GUI.
Re: mod_perl vs. C for high performance Apache modules
The original poster talked about C++ CGI programs. I have been using mod_perl since 0.7x days and I can tell you there is no way a fork+exec CGI program no matter what language its written in will come anywhere close to a perl handler written against the mod_perl Apache API in execution speed (when they are doing equivalnet types of work). Using C++ to build web applications is something developers who grew up in the heyday of client server would think is a good idea. In the internet web applications business by the time you get a C++ program debugged and ready to roll the market has evolved and your software is out of date. C++ is a good language for systems programming, databases, etc., but web apps need shorter life cycles. I had an investor question similar to the one we are talking about 3 years ago. I was questioned as to why we used Apache, mod_perl, and mysql instead of C++ and Oracle's DB and Web Devel kit. Needless to say our mod_perl systems have thrived while most of the investor's other investments have had their expensive hardware auctioned off on Ebay recently. The essence of mod_perl is that it allows to to take an idea and build a working prototype very quickly. When you prove that the prototype works you don't need to rewrite - mod_perl scales up better than any other web application technology available - period. -jon On Fri, 14 Dec 2001 [EMAIL PROTECTED] wrote: -- Jeff Yoak [EMAIL PROTECTED] on 12/14/01 12:58:51 -0800 This is something different. The investor is in a related business, and has developed substantially similar software for years. And it is really good. What's worse is that my normal, biggest argument isn't compelling in this case, that by the time this would be done in C, I'd be doing contract work on Mars. The investor claims to have evaluated Perl vs. C years ago, to have witnessed that every single hit on the webserver under mod_perl causes a CPU usage spike that isn't seen with C, and that under heavy load mod_perl completely falls apart where C doesn't. (This code is, of course, LONG gone so I can't evaluate it for whether the C was good and the Perl was screwy.) At any rate, because of this, he's spent years having good stuff written in C. Unbeknownst to either me or my client, both this software and its developer were available to us, so in this case it would have been faster, cheaper and honestly even better, by which I mean more fully-featured. Constructing the $r object in perl-space is an overhead that mod_perl causes. This overhead has been managed more effectively in recent versions of perl/mod_perl. A study done a few years ago probably involved machines with significantly less core and CPU horsepower than the average kiddie-games PC does today. Net result is that any overhead caused by mod_perl in the previous study may well have been either mitigated with better code or obviated by faster hardware [how's that for a sentence?]. Net result is that the objection is probably based on once- valid but now out of date analysis. -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 800 762 1582 -- C. Jon Larsen Chief Technology Officer, Richweb.com (804.307.6939) SMTP: [EMAIL PROTECTED] (http://richweb.com/cjl_pgp_pub_key.txt) Richweb.com: Designing Open Source Internet Business Solutions since 1995 Building Safe, Secure, Reliable Cisco-Powered Networks since 1995
Re: Comparison of different caching schemes
On December 14, 2001 03:53 pm, Robert Landrum wrote: At 6:04 PM -0500 12/14/01, Perrin Harkins wrote: That's actually a bit different. That would fail to notice updates between processes until the in-memory cache was cleared. Still very useful for read-only data or data that can be out of sync for some period though. The primary problem with everything mentioned thus far is that they are almost entirely based around the concept of a single server. Caching schemes that are both fast and work across multiple servers and process instances are very hard to find. After reading the eToys article, I decided that BerkeleyDB was worth a look. We discovered that it was very fast and would make a great cache for some of our commonly used database queries. The problem was that we are running on 5 different servers, load balanced by Big/IP. Again, taking my que from the eToys article, I began working on a data exchange system (using perl instead of C) which multicasts data packets to the listening servers. So far, our only problems have been with the deadlocking (solved with db_deadlock), and a few corrupt records. We did stuff based on kind of an Acceptable differences concept. Using round robinn dns, with predominantly winXX clients, you tend to get the same IP address from one request to tthe next. Changing, IIRC, on the dns cache timeout, from the soa record. With a bigIP or something, you can guarantee this user locality. So that leaves you with *appearing* to be in sync for the one local machine. Using a database with common connections from multiple machines or the one writer db machine, many read db machines concept, using replication or what have you for updates, you can present a pretty consistent database view, with a maximum difference on the read side of the replication time. We found that the database concept, plus using a local cache with a timeout of 5 seconds not only gave us a huge performance increase, but it gave us a maximum of about 6 seconds of data difference between machines. And since your average human viewer hits pages no faster than once every 20 seconds or so, it was pretty much invisible to the individual user. Of course search engines will be faster than this, but does being consistent for search engines matter all that much? I'm considering uploading to CPAN the stuff I've written for the caching, but haven't had the time to make it generic enough. I also haven't performed any benchmarks other than the Wow, that's a lot faster benchmark. One limitation to the stuff I've written is that the daemons (listeners) are non threaded, non forking. That and it's all based on UDP. Rob -- Jay yohimbe Thorne [EMAIL PROTECTED] Mgr Sys Tech, Userfriendly.org
Re: Comparison of different caching schemes
The thing you were missing is that on an OS with an aggressively caching filesystem (like Linux), frequently read files will end up cached in RAM anyway. The kernel can usually do a better job of managing an efficient cache than your program can. For what it's worth, DeWitt Clinton accompanied his first release of File::Cache (the precursor to Cache::FileCache) with a benchmark showing this same thing. That was the reason File::Cache was created. While that's true, there are still some problems with a file cache. Namely to get reasonably performance you have to do the directory hashing structure so that you don't end up with too many files (one for each key) in one directory. Thus for every add to the cache you have to: * stat each directory in the hash path and create it if it doesn't exist * open and create the file and write to it, close the file A similar method is required for reading. All that still takes a bit of time. This is where having some shared memory representation can be a really help since you don't have to traverse, open, read/write, close a file every time. Witness the performance of IPC::MM which seems to be mostly limited by the performance of the Storable module. I'm planning on doing another test which just stores some data without the 'streaming' to see which examples are really limited by Storable and which by their implementation, this might be useful for some people. And ++ on Paul's comments about Devel::DProf and other profilers. Ditto again. I've been using Apache::DProf recently and it's been great at tracking down exactly where time is spent in my program. If you have any performance problems, definitely use it first before making any assumptions. One question though, I have a call tree that looks a bit like: main - calls f1 - calls f2 - calls f3 - calls f2 The two calls to f2 may take completely different times. Using 'dprofpp -I', I can see what percentage of overall time is spent in 'f1 and children', 'f3 and children' and 'f2 and children'. But I can't see an easy way to tell 'time in f2 and children when f2 was called from f1' (or ditto for f3). Does that make sense? Rob
Re: load balancing on apache
My recommendation is that you do none of the things that you are looking at for optimal performance. Instead, opt for a seperate hardware solution. We went through this about a year ago when we were architecting a solution for my employers site. Admittedly, takes more traffic than you do, but we found that the dedicated hardware device offers many advantages (including layer 7 routing capablity) which we have found to be extremely useful and well worth the extra cabbage. Cisco (and several other folks as well) make some fine load balancing hardware devices. Alteon makes one, I know . We evaluated it, but we got a better price and better support from Cisco so we went with the CSS even though I was as impressed with their device. I'm sure that there are lower end alternative, but it depends on what kind of load balancing you want to do. Do you want to do round robin? If not, then what criteria do you want to use? - Original Message - From: Steven Lembark [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, December 14, 2001 3:15 AM Subject: Re: load balancing on apache -- Hemant Singh [EMAIL PROTECTED] Hi All I am planning to host an application and its size is going to be big one , so expect the concurrent number of connection s to be around 2200.To combat the same , want to perform load sharing on 3-4 servers.So the ide is to put one machine on external IP and this machine , after receiving the requests would forward them to any of the other three machines having the application deployed and running on the same environment.Pls suggest how can i achieve this on apache. Randal Schwartz had a good article on this about a year ago. You can use the re-write phase to balance the load w/in Apache if you want to. Alternatives include round- robin DNS and separate load balancing software. -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 800 762 1582
Re: mod_perl vs. C for high performance Apache modules
Flamebait For some really high performance sites, compiled C is the way to go. It's faster and as long as you remove all compilers from the machines in question, it's also more secure. /flamebait Having said that, I will also add that the downside is that in order to keep pace with your competitors who are writing code in Perl, PHP, and Python, it is going to cost you some serious dollars. You have to have deep pockets and in house coders to make it worth looking at, which normally limits this kind of thing to the Fortune 100. For the entire rest of the planet, perl is a perfectly good solution. IMHO, Jimi - Original Message - From: Perrin Harkins [EMAIL PROTECTED] To: Thomas Eibner [EMAIL PROTECTED]; Jeff Yoak [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, December 14, 2001 3:32 PM Subject: Re: mod_perl vs. C for high performance Apache modules So I'm trying to show that mod_perl doesn't suck, and that it is, in fact, a reasonable choice. Though within these limits it is still reasonable to point out the development cycle, emotionally it is the least compelling form of argument, because the investor has a hard time removing from consideration that given our particular situation, there was a very fast solution in using his C-based routines. Well, that is the primary reason for using Perl over C, and you really have to count maintenance and the relative likelihood of C-ish bugs like buffer overflows as part of it. Well-coded C should be faster than Perl, but Perl is fast enough for nearly any web-based application. If this guy saw CPU spikes, he probably had something else wrong, like running out of memory. You might find this article aboout C and Perl performance useful: http://www.perl.com/pub/a/2001/06/27/ctoperl.html - Perrin
Re:[Rewrite article] Randal Schwartz article on load balancing in Epache
I would like to see the article of Randal Schwartz ,.. Will some one help me out with this - Original Message - From: Steven Lembark [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, December 14, 2001 2:45 PM Subject: Re: load balancing on apache -- Hemant Singh [EMAIL PROTECTED] Hi All I am planning to host an application and its size is going to be big one , so expect the concurrent number of connection s to be around 2200.To combat the same , want to perform load sharing on 3-4 servers.So the ide is to put one machine on external IP and this machine , after receiving the requests would forward them to any of the other three machines having the application deployed and running on the same environment.Pls suggest how can i achieve this on apache. Randal Schwartz had a good article on this about a year ago. You can use the re-write phase to balance the load w/in Apache if you want to. Alternatives include round- robin DNS and separate load balancing software. -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 800 762 1582
Re: load balancing on apache by IP CHAINING
IP chaining can be done in Java Webserver, How to do it in Apache Webserver. Please let the Ring know this, Thanks in advance, Regards, Anand - Original Message - From: Derek Jones To: Hemant Singh ; [EMAIL PROTECTED] Cc: Derek G Jones Sent: Friday, December 14, 2001 7:29 PM Subject: RE: load balancing on apache Hi all, You can do load balancing using ipchains as well. Can't remember the program name offhand, but if I have time I'll look it up and let the list know. Only works if your servers are Linux of course. Kind regards Derek. --Derek Jones 1051, Bollinger Road,Tel: 717 359 8817 Littlestown,Mobile: 717 977 4556 PA, 17340, USAEmail: [EMAIL PROTECTED]AIM: scunacc
Re:[Rewrite article] Randal Schwartz article on load balancing inEpache
-- Anand R [EMAIL PROTECTED] I would like to see the article of Randal Schwartz ,.. Will some one help me out with this Check out his website at stonehenge.com. Look for something like poor man's load balancer. Trick was to use the URI [post read?] to re-write the URI and post it to another system based on the estimated load any other balancing criteria. You might be able to find it via google also. -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 800 762 1582
Reg. Unsubscription from Mod-perl Maling list.
Hi, Can u pls unsubscribeme form the mod-perl mailing list. Expecting the same With Regards.Jayaraj G VWeb DeveloperScapevelocity Net Solutions,15, Jeevarathnam Nagar, Adyar,Chennai - 600020Ph: 91-44-4916623Mobile: 98411 61434Mail: [EMAIL PROTECTED]Yahoo Id : [EMAIL PROTECTED]Visit us at: www.scapevelocity.com
