How Fast & Stable??
Hi We are setting up a web storefront and I have come across Zope towards the end of a long and frustrating evaluation process. To be frank, when you get up close most application servers just don't cut it. ColdFusion, for example, seems to have some serious reliability problems. Until I spotted Zope, I was pretty much resigned to a belt-and-braces solution with Perl/Velocigen or Tcl/AolServer. Not an easy route, but at least it would be reliable. Compared to raw coding, a Python/Zope/Apache/Solid solution looks attractive, to say the least. But at this relatively early stage in its development, can Zope truly deliver? So a plea to you folks who are actually using Zope 2 in a production setting - is it fast enough and stable enough for us to (literally) bet our house on? It will be running unattended on a remote server (probably Linux). We are planning a niche storefront site which will probably get modest traffic of around 50,000 hits a day with around 3,000 products in the database. Zope is obviously a great product, and most people on this list will be evangelists. But I really would appreciate your objective views. If you prefer privacy, please contact me direct: geoff@productivity.co.uk. Thanks Geoff Caplan
Geoff Caplan wrote:
To be frank, when you get up close most application servers just don't cut it. ColdFusion, for example, seems to have some serious reliability problems. Until I spotted Zope, I was pretty much resigned to a belt-and-braces solution with Perl/Velocigen or Tcl/AolServer. Not an easy route, but at least it would be reliable.
Understood.
Compared to raw coding, a Python/Zope/Apache/Solid solution looks attractive, to say the least. But at this relatively early stage in its development, can Zope truly deliver?
Just a quick correction, though -- chances are that Zope is older than Tcl/Aolserver, and probably older than the Perl binding to Velocigen. Zope is the unholy union of three former pieces of software: 1) Bobo, the Python Object Publisher. A free pieces of software, first used in a commercial setting in 1996. 2) Principia, Digital Creation's commercial appserver upsell from Bobo. First used in a commercial setting in May 1997. 3) Aqueduct, relational database integration with Bobo/Principia. First used in a commercial setting in Jan 1997. The project that drove Principia's development was a online classified ad system for newspapers. By the time our involvement with the product finished in 1998, it was serving 100 papers, over a million hits a day, and over a million ads a week. The death march on that project taught us a *whole* lot about scale and reliability. The Zope2 *architecture* represents the fulfilled vision of those goals. (Zope2 itself went out missing some of the extras, like spreading your object database storage across multiple files.)
So a plea to you folks who are actually using Zope 2 in a production setting - is it fast enough and stable enough for us to (literally) bet our house on? It will be running unattended on a remote server (probably Linux). We are planning a niche storefront site which will probably get modest traffic of around 50,000 hits a day with around 3,000 products in the database.
Oh its definately fast enough, unless all 50k hits happen in the same minute. :^) Seriously, Zope should do over ten hits per second for even complicated pages, over 30 hits per second for less complicated pages. One programming note: within the next month we'll check in the work for FastCGI, meaning you can sit behind Apache and not pay the fork tax.
Zope is obviously a great product, and most people on this list will be evangelists. But I really would appreciate your objective views. If you prefer privacy, please contact me direct: geoff@productivity.co.uk.
Oh, you wanted *objective* views. :^) --Paul
One programming note: within the next month we'll check in the work for FastCGI, meaning you can sit behind Apache and not pay the fork tax.
Please excuse my ignorance here, and not wishing to take too much of your precious time Paul, but why use FastCGI ? wasn't PCGI supposed to be even better or have I been brainwashed by spending too long on Mr Bauer's homepage ? chas
At 12:39 AM 9/28/99 +0800, chas wrote:
One programming note: within the next month we'll check in the work for FastCGI, meaning you can sit behind Apache and not pay the fork tax.
Please excuse my ignorance here, and not wishing to take too much of your precious time Paul, but why use FastCGI ? wasn't PCGI supposed to be even better or have I been brainwashed by spending too long on Mr Bauer's homepage ?
The C FastCGI library from OpenMarket wasn't multithread-capable; Digital Creations is doing a Medusa implementation that will be. This eliminates most of the problems with FastCGI vs PCGI, and can even gain because it removes the 'fork tax' if you have Apache with mod_fcgi. This is also a good way to go for broad webserver compatibility, since there are servers besides Apache that support FastCGI, and last I heard mod_pcgi wasn't fully functional compared to mod_fcgi.
chas wrote:
One programming note: within the next month we'll check in the work for FastCGI, meaning you can sit behind Apache and not pay the fork tax.
Please excuse my ignorance here, and not wishing to take too much of your precious time Paul, but why use FastCGI ? wasn't PCGI supposed to be even better or have I been brainwashed by spending too long on Mr Bauer's homepage ?
Phillip provided almost all of the answer, so I'll just add a couple of other points: 1) FastCGI lets you connect across a network using TCP, not just on the local machine. Jeff has been working on this for PCGI. 2) FastCGI lets you specify a pool of servers to connect to. If one process isn't available, I believe you'll be connected to the next one. 3) The company selling the commercial version of FastCGI is putting some load balancing algorithms in. For us, FastCGI is attractive for one very simple reason: a large group of people outside Digtial Creations is doing the work. It is very important to have a non-forking request model on Apache/Netscape/IIS, and we just aren't in the position to keep the expertise for all of those server APIs. This does *not* mean that we are dropping PCGI support in Zope. Right now, it just means we are *adding* FastCGI support. --Paul
Paul Everitt wrote:
One programming note: within the next month we'll check in the work for FastCGI, meaning you can sit behind Apache and not pay the fork tax.
What happened to mod_pcgi (or whatever it's name was ;), the apache module version of PCGI. I was under impression that it as almost ready for real-world use ? ------------------ Hannu
participants (5)
-
chas -
Geoff Caplan -
Hannu Krosing -
Paul Everitt -
Phillip J. Eby