Re: mod_perl v. FastCGI
I've been using FastCGI for a bit now in a variety of configurations
and even done some distributed programming with it (which is
exceedingly cool). I really like it! There's a lot more to it than I
had previously assumed.
I'll do a tech talk on it - is there a slot for this next one? Lightning
talk is not going to do it justice.
Paul
On Fri, Dec 13, 2002 at 05:53:00PM +, Paul Makepeace wrote:
> OK, so this is part II I suppose. The perl webapp mantra seems to be
> "use mod_perl!" but IM[OE] it's a dog of an environment. Sure, lots of
> people love it, but I think that's mostly because they've suffered
> through trauma and it has developed that appeal of a
> conquered-but-has-it-got-something-up-its-sleeve-to-shaft-you-
> again-oh-yes! foe that rather than some inherent goodness or other
> +ve characteristic (am I way off-track? That's certainly been my
> experience.)
>
> I've had the fortune to work recently on a heavily trafficked site that
> uses FastCGI - man, what a nice experience! It just works. And, it ports
> to zeus amongst other beasts. I.e. you're not locked into Apache and all
> *its* warts.
>
> Has anyone else used FCGI recently? (I heard it was a bit shabby in
> yonder days.) In particular what situations is mod_perl a real win, and
> worth putting up with the pain?
>
> ("but mod_perl's great!"; I know mod_perl is quite great, I'm more after
> a comparison here.)
>
> http://www.fastcgi.com/ fwiw
>
> Paul
>
> --
> Paul Makepeace ... http://paulm.com/
>
> "What is a gaggle of geese? Don't know."
>-- http://paulm.com/toys/surrealism/
>
--
Paul Makepeace ... http://paulm.com/
"What is knowledge? Nectar of the gods!"
-- http://paulm.com/toys/surrealism/
Re: mod_perl v. FastCGI
On Saturday, Dec 14, 2002, at 00:17 Europe/London, Dirk Koopman wrote: Nice article, but doesn't really answer the question, which is: is FastCGI as scalable as mod_perl? I suspect the answer depends on what exactly you mean by "scalable". Usually the answer to questions like this is "FastCGI is better for some things and mod_perl is better for others". Also just because something is slightly faster doesn't mean its necessarily any better, for example non OO code in Perl is usually faster (for the computer to run if not for the programmer to extend) than OO code. Has anyone actually done any benchmarks, are there any numbers? Looking on google finds many benchmarks. Whether the benchmarks say the same thing is unlikely! http://www.dmst.aueb.gr/dds/pubs/conf/2002-SANE-DynCont/html/ dyncont.html "Apart from that, it is obvious that FastCGI is the fastest protocol we tested. It managed to handle more concurrent clients than every other protocol, even when the think time was minimum. It also managed to produce more traffic than every other protocol. Mod_perl also provided satisfactory performance and in fact managed to scale very well when the think time raised, doubling the served clients for a 3 second increase." Although looking at many of the graphs doesn't seem to show significant differences between mod_perl and FastCGI. There are other FastCGI-type technologies as well like SpeedyCGI and pperl to compare. I would take all these benchmarks with a large handful of salt the people supplying them either tend to have an agenda in supporting one technology over another or are simply more familiar with one technology and optimise for that better. Really you have to read all the small print and you often find the benchmarks are basically flawed since the sort of benchmark code often doesn't reflect real world useage. Let's not mess about, our victim (says he) needs 300 page views a second. This isn't a matter of opinion here, this is solid number territory. Benchmarks are really still opinion and not hard fact since it depends on exactly how the benchmarks are written and the assumptions they make. Because one benchmark on the web seems faster doesn't mean your code will automatically run faster. You wouldn't know until you try it and even then you may find a slower technology is "better" for other reasons. -- Steve Mynott <[EMAIL PROTECTED]>
Re: mod_perl v. FastCGI
On Sat, Dec 14, 2002 at 04:04:28PM +, Simon Wilcox wrote: > On Sat, 14 Dec 2002, Nicholas Clark wrote: > > > Having looked at some of the crap in HTML, it seems to be lots of font and > > colo(u)r tags, things more tersely done once in a CSS, especially if the > > spec is allowed to say "we're aiming at $modern browser" where modern is > > defined to mean CSS works. And that is consistent with my view that unless > > Modern ? CSS working ? HAH ! Indeed. Few browsers deal with CSS 2 well - most implement parts of the specification and ignore other parts. I agree with Nicholas that simple things like colour, font and text settings are best done with CSS, but much of CSS 2 is best ignored unless you have lots of time and patience. > I just spent a day struggling to get a nice css page working only to > discover that M$ haven't bothered to implement "position: fixed" so all > that work went down the pan. Opera supports this even worse - I've yet to understand why it positions elements where it does. My solution for IE was to make the CSS degrade gracefully by dealing with positioning in a "body>div#id" CSS selection which IE doesn't understand. > Bah. hate hate hate. I'm glad I'm not the only one... Tom
Re: mod_perl v. FastCGI
On Sat, 14 Dec 2002, Nicholas Clark wrote: > Having looked at some of the crap in HTML, it seems to be lots of font and > colo(u)r tags, things more tersely done once in a CSS, especially if the > spec is allowed to say "we're aiming at $modern browser" where modern is > defined to mean CSS works. And that is consistent with my view that unless Modern ? CSS working ? HAH ! I just spent a day struggling to get a nice css page working only to discover that M$ haven't bothered to implement "position: fixed" so all that work went down the pan. Bah. hate hate hate. Simon. -- "Bunch of flowers!"
Re: mod_perl v. FastCGI
On Sat, Dec 14, 2002 at 12:17:27AM +, Dirk Koopman wrote: > Let's not mess about, our victim (says he) needs 300 page views a > second. This isn't a matter of opinion here, this is solid number > territory. Well, quantified estimate territory. But that's not the important part - we have a number, and it's not 42 > Mind you he hasn't said how big the pages are. I would just like to > remind our viewers that 100Mb / sec / 300 = 33 Kbytes. This is a bit > erm... small in modern HTML usage and also takes no account of boring > things like latency, processing overhead, collisions, speed of the > internet in general etc etc etc. Modern HTML quite often seems to use a lot more tags than would seem necessary to get the job done. Given that he says he wants to serve enormous numbers of pages, it may well become necessary to make part of the spec that the pages to be served will need to be "coded" in efficiently HTML. Actually, I'll take the quotes out. They need to be coded in a proper programmer sense, rather than typed out (on infinite keyboards) by some "HTML coder" Having looked at some of the crap in HTML, it seems to be lots of font and colo(u)r tags, things more tersely done once in a CSS, especially if the spec is allowed to say "we're aiming at $modern browser" where modern is defined to mean CSS works. And that is consistent with my view that unless the web should work well enough in links, w3m or an HTML-to-speech converter, as I'm not aware of links or w3m screwing CSS up, for example by picking unreadable font sizes or font colours. Given that google can do very efficient HTML, there's no reason why anyone else can't either. Particularly if it's cheaper to pay people to get the HTML right, rather than buying twice as much hardware and bandwidth. Nicholas Clark
Re: mod_perl v. FastCGI
On Fri, 2002-12-13 at 22:33, Dave Hodgkinson wrote: > On Fri, 2002-12-13 at 17:53, Paul Makepeace wrote: > > > Has anyone else used FCGI recently? (I heard it was a bit shabby in > > yonder days.) In particular what situations is mod_perl a real win, and > > worth putting up with the pain? > > Did goole not find the paper wot I wrote for Emap? > > http://www.hodgkinson.org/comparison.html erm.. I don't agree with the original statement that programming for FastCGI is intrinsically easier than mod_perl (and anyway: who uses vanilla mod_perl?). But... Nice article, but doesn't really answer the question, which is: is FastCGI as scalable as mod_perl? Has anyone actually done any benchmarks, are there any numbers? Let's not mess about, our victim (says he) needs 300 page views a second. This isn't a matter of opinion here, this is solid number territory. Give the man something useful to chew on. Mind you he hasn't said how big the pages are. I would just like to remind our viewers that 100Mb / sec / 300 = 33 Kbytes. This is a bit erm... small in modern HTML usage and also takes no account of boring things like latency, processing overhead, collisions, speed of the internet in general etc etc etc. I am still old, so don't hit me too hard. Dirk
Re: mod_perl v. FastCGI
On Fri, 2002-12-13 at 17:53, Paul Makepeace wrote: > Has anyone else used FCGI recently? (I heard it was a bit shabby in > yonder days.) In particular what situations is mod_perl a real win, and > worth putting up with the pain? Did goole not find the paper wot I wrote for Emap? http://www.hodgkinson.org/comparison.html -- Dave Hodgkinson <[EMAIL PROTECTED]>
Re: mod_perl v. FastCGI
Paul Makepeace wrote: Has anyone else used FCGI recently? (I heard it was a bit shabby in yonder days.) In particular what situations is mod_perl a real win, and worth putting up with the pain? I haven't used it in a while, but back when I tried it you had no access to Apache's API. IOW, it was just content generation but none of the other cool stuff (auth/authz, logging, etc). Other things I'd put in favour of modperl are the Apache::* namespace on CPAN and the mailing list. -- Robin Berjon <[EMAIL PROTECTED]> Research Engineer, Expway 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
mod_perl v. FastCGI
OK, so this is part II I suppose. The perl webapp mantra seems to be
"use mod_perl!" but IM[OE] it's a dog of an environment. Sure, lots of
people love it, but I think that's mostly because they've suffered
through trauma and it has developed that appeal of a
conquered-but-has-it-got-something-up-its-sleeve-to-shaft-you-
again-oh-yes! foe that rather than some inherent goodness or other
+ve characteristic (am I way off-track? That's certainly been my
experience.)
I've had the fortune to work recently on a heavily trafficked site that
uses FastCGI - man, what a nice experience! It just works. And, it ports
to zeus amongst other beasts. I.e. you're not locked into Apache and all
*its* warts.
Has anyone else used FCGI recently? (I heard it was a bit shabby in
yonder days.) In particular what situations is mod_perl a real win, and
worth putting up with the pain?
("but mod_perl's great!"; I know mod_perl is quite great, I'm more after
a comparison here.)
http://www.fastcgi.com/ fwiw
Paul
--
Paul Makepeace ... http://paulm.com/
"What is a gaggle of geese? Don't know."
-- http://paulm.com/toys/surrealism/
