Best tool for the job
Please contact me for text I would also sign, not only acknowledge or if post got broken during one of many server upgrades. I will be most grateful.
Sometimes, I really am an idiot. A couple of years ago I was involved in development of a front-end Zope application for a major Slovenian ISP with more than 100 000 users. No matter what we did, Zope just wasn’t fast. In fact it was so slow, it was soon abandoned for one more suitable solution.
The failure of our project was largely my fault, because I haven’t made sure Zope was a good fit for what we wanted. I learned a lot, but it also left a bitter aftertaste and a question, why are people using it?
The obvious answer is of course, because it DOES fit their needs. It’s just that they are not building a site or an application that needs to handle few hundred simultaneous requests. They handle a few at most, so Zope or Plone or what-have-you is more than speedy enough and it’s their features that count.
It really took me awhile to grasp this and it only became really clear this week, after reading a little Plone benchmark and having a discussion with Sebastjan about slowness of Slovenian sites.
On a positive note, we generate pages in less than 6 ms now and can reduce it even further, if needed.
Of course sometimes you DO build applications that will serve a lot of requests simultaneously, and zope just doesn’t cut it.
Comment by Florian — September 28, 2005 @ 11:02 pm
If you had actually read the sources of Zope first, you would probably have noticed that it is a “synchronized” version of Medusa, a Python library for asynchronous high-performance multiprotocol server written by Sam Rushing.
Zope can’t handle a fraction of what Medusa manages because every request to an object is met with a thread. In Zope 1 and 2, only static content is served asynchronously. Zope 3 re-introduced asynchronous programming but it is at odd with the rest of the “installed base”, the running code, products, applications, etc.
So, have a look at the original Medusa:
http://nightmare.com/medusa/index.html
or the version maintained by Andrew Kuchking:
http://www.amk.ca/python/code/medusa.html
or my own fork of it:
http://svn.berlios.de/wsvn/allegra
It’s never too late to do good.
Comment by Laurent Szyster — September 29, 2005 @ 1:31 am
As it happens I did back then. I was curious why Zope couldn’t handle more when neither processor or disk IO were fully utilized. I don’t remember what I did or didn’t find though.
I know about Medusa and quite like it, but I didn’t know about allegra and thank you for letting me know. I’ll certainly take a look at it.
These days I normally work with mod_python, since it gives me the performance I need and I don’t really need Zope-like features.
Comment by markos — September 29, 2005 @ 1:39 am
I benchmarked Plone, mod_python, php, websphere and Lotus Domino (just a simple report presentation)
Plone followed by domino were the worst performers. mod_python was the fastest of the bunch.
Comment by Anthony — September 29, 2005 @ 3:28 pm
I left some simple benchmarking of a Quixote app over at jkx’s site: http://www.larsen-b.com/Article/217.html and included a Medusa benchmark.
Quixote is not designed for multiple threads of execution and uses fork process model. A simple single process server delivers about the same performance. SCGI and Apache or SCGI/lighttpd are about the fastest platform for Quixote apps and allow the web server to deliver truly static content.
I originally went the Quixote route some years ago now because it is light and quite fast applications can be developed, quickly, using modest hardware. For my mix of not for profit and business apps it was a good choice… really did not want to master multiple frameworks.
Comment by Mike Watkins — September 29, 2005 @ 8:32 pm