zope vs. siteserver from ms.siteserver newsgroup
Here's an exchange I had with a guy in the MS Site Server general Usenet Newsgroup... can anyone find exception with his or my arguments? Additionally, he doubts the ability of Zope to handle large sites (near the end of the message). Any clarifications are appreciated.... I wrote: Thanks for your comments! In article <74D4DC853648D311823F00E018900AD5309923@MAIL-BLN.maghan.com>, Thomas Tomiczek <t.tomiczek@maghan.com> wrote:
Hm - you gie scalability a tie. I think, MS is the winner here.
No, actually, it was stability... I didn't compare the two for scalability. Its an undertaking I didnt have time for.
SiteServer uses ASP for development, but you can also use other stuff (ISAPI Extensions, for example). The paradigm is to put mot or all of the more complex logic into COM-objects, which most ot the time are compiled natively.
On the opposite, ZOPE is interpreted, not only the templates, even the server itself. No paradigm like COM is part of the game (though it might be extended). So ZOPE will be less speedy.
I might take exception with this. ASP itself is interpreted (obviously), and isn't the speediest interpreted scripting framework in the world... a recent benchmark of a "hello world" program in ASP/VBScript on IIS pumped out an underwhelming 9.53 req/sec. Please see http://www.google.com/search?q=cache:41196118&dq=cache:www.bitmechanic.com/m ail-archives/modperl/current/0151.html for an explanation. There are no hard numbers on Zope, but ASP/VBScript is not a particularly well-performing web application development language as compared to PHP or mod_perl or other alternatives. As most of your presentation logic will be placed in ASP, it will be your bottleneck. It won't really matter that your COM logic is fast as hell. Please correct me if I'm misunderstanding the argument. Additionally, not all of Zope is written in Python. Key pieces of it are written in C for speed. And when you say "no paradigm like COM is part of the game", you should also know that Zope is completely object-oriented, whereas the ASP/Site Server combination is a mix of mostly procedural structures with some object oriented components (COM objects) thrown in. I don't know if you're criticizing design or function here...
Also: I really doubt the scalability of the ZOPE Object database, compared to the SQL Server that is part of the site server licensing. The ZOPE Object database - well - there are no benchmarks on it.
Agreed.
First Part: App Development: You are not really good with statements like "Additionally, the process of "decoding" some of Microsoft's Site Server-related error messages is tedious (e.g. "Server Object error ASP 0177:800401f3 Server.CreateObject failed, line 37, invalid class string")." - Sorry, THIS error message explains itself quite well.
Maybe you can tell me what it means in the context of the failure... it happens in the cmsample application that comes with Site Server.
"When you do this, you're basically extending the Zope environment by creating your own object types without having to know a high-level programming language (ala C++/Visual Basic COM object development)." - well, just you do it in a slow interpredet language, where C++ COM Objects will be speedy!
Hmmm. I don't know C++. This was my point. With Zope, I don't have to know C++ or even VB to develop object components. I just need to know how to point and click, plus I need to know a little bit of DTML (Document Template Markup Language).
"The power of this model is formidable. For example, I developed a "news item" object in 22 minutes which allows my users to add "news items" to their department for perusal by other department members." - nive. What about adding 100.000 news items. What is the performance then? This is unrealistic? OK, lets make an interface for a news server. 1 million messages a day. Youre dead.
Agreed. There isn't enough data. Does anyone in here run a Site Server based site that handles this kind of traffic? It'd be interesting to see what sort of hardware is required...
I really do not want to critisize you - it is only, that your statements are NOT backed up. I was also looking at ZOPE, and in my eyes - nice try. I still have to see a website working with it. A real site, say 10 million pages a day, all dynamic. Make a setup of Zope in a cluster with shared session. It can be done in site server.
I will forward your message to the Zope list to see if anyone can attest to running such a site.... Many, many thanks for all your comments!!
Thomas Tomiczek
-----Original Message----- From: Chris McDonough [mailto:mcdonc@iqgroup.com] Posted At: Mittwoch, 13. Oktober 1999 00:54 Posted To: general Conversation: Site Server vs. Zope... Subject: Site Server vs. Zope...
I've come up with a very basic Site Server vs. Zope (an open-source application server) comparison from the perspective of using the packages to develop Intranet sites... I'd be pleased if anyone could correct or comment on the analysis.
The comparison is at http://sharon.iqgroup.com/zopevssiteserver.html
Many thanks!
Chris
Sent via Deja.com http://www.deja.com/ Before you buy.
Chris McDonough wrote:
Here's an exchange I had with a guy in the MS Site Server general Usenet Newsgroup... can anyone find exception with his or my arguments? Additionally, he doubts the ability of Zope to handle large sites (near the end of the message). Any clarifications are appreciated....
...
First Part: App Development: You are not really good with statements like "Additionally, the process of "decoding" some of Microsoft's Site Server-related error messages is tedious (e.g. "Server Object error ASP 0177:800401f3 Server.CreateObject failed, line 37, invalid class string")." - Sorry, THIS error message explains itself quite well.
Maybe you can tell me what it means in the context of the failure... it happens in the cmsample application that comes with Site Server.
I definitely prefer tracebacks to this.
"When you do this, you're basically extending the Zope environment by creating your own object types without having to know a high-level programming language (ala C++/Visual Basic COM object development)." - well, just you do it in a slow interpredet language, where C++ COM Objects will be speedy!
Hmmm. I don't know C++. This was my point. With Zope, I don't have to know C++ or even VB to develop object components. I just need to know how to point and click, plus I need to know a little bit of DTML (Document Template Markup Language).
Definitely. As noted,if you need blinding speed, you can write extensions in C, C++, (Objective C?) .... Additionally, it is worth noting that there is nothing inherently 'speedy' about C++ COM.
"The power of this model is formidable. For example, I developed a "news item" object in 22 minutes which allows my users to add "news items" to their department for perusal by other department members." - nive. What about adding 100.000 news items. What is the performance then? This is unrealistic? OK, lets make an interface for a news server. 1 million messages a day. Youre dead.
Agreed. There isn't enough data. Does anyone in here run a Site Server based site that handles this kind of traffic? It'd be interesting to see what sort of hardware is required...
22 minutes? I did with Zope it in 7 ;-) A direct web interface to news is not a good test of a webserver, since you are only adding data to the database, and that can be done without the webserver. Simply map the messages into an SQL database, say Oracle for example, running on a seperate machine, use the DB-DA for your chosen SQL server, and now your webserver is bored. It is in client requests that you need to be concerned with. Here IIS incurrs two penalties, one is IIS itsself, the other is the OS it is running on.
I really do not want to critisize you - it is only, that your statements are NOT backed up. I was also looking at ZOPE, and in my eyes - nice try. I still have to see a website working with it. A real site, say 10 million pages a day, all dynamic. Make a setup of Zope in a cluster with shared session. It can be done in site server.
I will forward your message to the Zope list to see if anyone can attest to running such a site....
Many, many thanks for all your comments!!
Show me a site running _all_dynamic_ pages on SiteServer that handles over 115 requests per second. It is nice to play what-if, but unless one has an example of another site doing that many requests on his/her side of the aisle, the request is meaningless. I don't mean to be rude, but I know of no 10Mill/day (115.74/sec) dynamic page displays server running on a *single* MS's SiteServer. -- "They laughed at Columbus, they laughed at Fulton, they laughed at the Wright brothers. But they also laughed at Bozo the Clown." -- Carl Sagan
While the issues you're discussing are, of course, important in the larger context, I was a little surprised when I reached your original message *waaay* at the bottom:
packages to develop <my EMPH>Intranet</my EMPH> sites...
Whose *intranet* servers are going to get anywhere near 10 million hits per day? IBM's? Zope should have *no* problem handling a reasonably sized intranet on even modest hardware. In any case, I trust the DC folks, and they've described how Zope can scale to pretty much any level one might need.
I cannot imagine an *intranet* site that gets 10 M-hits per day. If you really want that kind of traffic, look at AOL server, which uses the same fast asynchronous I/O model that medusa is built on. Also note that AOL Server is to TCL what Zope/Medusa is to Python: in both cases much of the work is done by a "slow" interpreted language. AOL claims that their servers (how many?) collectively handle 28,000 hits *per second*. I was impressed. Here is an idea: replace ZServer with AOLServer and see what Zope can do.
In article <38066A72.451638C5@ics.uci.edu>, Terrel Shumway <tshumway@ics.uci.edu> writes
Here is an idea: replace ZServer with AOLServer and see what Zope can do.
I don't think AOLServer is still available for NT though. ------- Regards, Graham Chiu gchiu<at>compkarori.co.nz
participants (5)
-
Bill Anderson -
Chris McDonough -
Evan Simpson -
Graham Chiu -
Terrel Shumway