Against the CGI-is-slow chorus (Re: CGI with Python: advantages?)

Cameron Laird claird at starbase.neosoft.com
Mon Aug 7 07:15:37 EDT 2000


In article <see-3573B0.20403906082000 at news.dnai.com>,
Sam Penrose  <see at message.body> wrote:
			.
			.
			.
>[[Redundancy warning: I have made similar posts recently, but they seem 
>to bear making again.]]
>
>I disagree with all of this. Here's why:
>
>I work for a company that does ecommerce sites, using Python CGIs to 
>move data between MySQL and HTML. Our busiest site (CGI page views in 
			.
		[many apt details]
			.
			.
>for data that isn't in RAM. That in mind, I want to ask:
>
>1) Does anyone have firsthand experience of a slow website served on 
>contemporary hardware that was made fast by moving away from Python 
>CGIs? If so, what were the details?
>
>2) Who exactly needs a faster Python interpreter for serving CGIs, who 
>wouldn't be better served by upgrading their hardware? Even a non-profit 
>that is handling tens of thousands of dynamic requests a day can 
>probably find funding for a better server a lot easier than they can get 
>more programmer/sysadmin hours.
>
>3) Is it time for the received wisdom to state that CGI performance 
>should not be worried about unless your hardware is obsolete, you are 
>serving dozens of dynamic pages a minute, or you have evidence to the 
>contrary?
>
>-- 
>spenrose at well dot com

Moshe figured I'd chime in with a, "But CGI is OK!" Sam's already
doing that better'n I can, so I'll echo the discussion at a
slightly different level.

Do you know Philip Greenspun <URL:http://philip.greenspun.com/>?
As he observes, there are very few authors of coffee-table books
on, say, Oracle design <URL:http://photo.net/wtr/thebook/>.  He's
the one.  He's also a world-class expert on world-class Web sites.
He's also maddeningly arrogant and close-minded on these subjects;
that is, that's how techies generally react to him, because he
simply says, "I've got a combination that reliably handles millions
of hits a day, and better things to do than diddle with Apache
module update tweaks."

So, my summary of the very good points Alex, Moshe, and Sam have
made is:
1.  Try Python.  It takes only a little time to
    give it a chance.
2.  Unless you're already in the position where
    you know a lot about the comparisons, mod_perl
    vs. FASTCGI vs. Enhydra vs ... probably won't
    make a performance difference you'll be able
    to perceive.
3.  Check out Zope, Enhydra, ...  Depending on
    your needs and attitudes, you might feed these
    IMMENSELY rewarding.
4.  Tracking down memory leaks makes men old before
    their time.

Incidentally, Philip says everyone in the world should be coding
in Tcl (only because the LISP Machine people were bad at business,
but that's another story) within AOLServer <URL:http://
www.linuxworld.com/linuxworld/lw-1999-09/lw-09-aolserver_2.html>
against Oracle <URL:http://
www.linuxworld.com/linuxworld/lw-1999-10/lw-10-aolserver_4-2.html#sidebar>
over HP-UX.  That is, *he* does, and sees no reason to change.
-- 

Cameron Laird <claird at NeoSoft.com>
Business:  http://www.Phaseit.net
Personal:  http://starbase.neosoft.com/~claird/home.html



More information about the Python-list mailing list