[Zope] why shall I use Zope?
Andreas Kostyrka
andreas@kostyrka.priv.at
21 Sep 2002 11:02:23 +0200
Am Mon, 2002-09-09 um 11.21 schrieb Newbie:
> Hi,
>
> can someone give me some ideas on what Zope can be useful for small scale
> website?
> I understand zope as a good platform to build web application (medium to
> large scale) and portal solution.
> But if I have only 20 pages of websites and news I probably update only once
> a week, is Zope still useful?
Well, there are certain pluses, like being able to generate the website
dynamically. And this includes automatically correct intrasite links,
content-management, etc.
>
> To use Zope, I still need to understand HTML if I create the content using
> DTML document.
> One of the good advantage its ZMI.
> But not everyone understand HTML well and ZMI might not be a good tools to
> update one's website.
Well, yes and no. For usual text oriented documents Structured Texts
seems to be sufficient.
>
> There are a lot of website builder such as Frontpage.
> With frontpage, one can manage his/her website locally, update it and
> synchronize the contentt with the server.
Well, Frontpage is a bit like a NISSAN 300ZX. Nice to look on. At least
as long as you do not intrude into the technical details below the skin,
...
>
> Could anyone just give me idea why would I prefer to use Zope for small
> scale website?
> >From $ standpoint, zope hosting is more expensive than other frontpage, php
> hosting (of course for small scale site)
Well, this is certainly true, because Zope is hosted not by "uploading
precalculated .html pages", but by dynamically calculating these upon
request. Things that are rather trivial with Zope, and which are not
possible with this "static pages" modell:
- Talkback sections
- including actual data like
* references to the current time (like in "this was posted 16 hours
ago")
* count of active sessions ("there are x Users and y Guests online")
* references to the current user ("You are coming from 10.11.12.13" or
changing the page view upon the pages viewed before: "News Items (X
items not shown which you have already seen:")
* creating different views of your content depending upon the User
Client. For example different styles of CSS or a text only version
for certain clients like lynx, Search-Engine-Crawlers, ..
- calculate dynamically the navigation.
* Zope.org download area is known to use ZCatalog searches just to
generate the lists of Products.
* Workflow (just put some properties like "published" or
"published_on" on your Data items)
Well, yes you can probably stick with static publishing for your
projects. (small + once a week updates)
But should the project ever grow (in size or in features) you will have
these options:
1 add the dynamic features via "cgi" scripts. (or .ASP, .php, .jsp)
2 switch to Zope.
3 switch to some prefabricated Content Management System.
2+3 have some common drawbacks and advantages:
- you will need to rework your whole content to fit the organization of
the CMS.
- you need probably to have hosting account that allows for running CGIs
or even long-running CGIs
+ more professional feel of the site. (Actually this refers to the
technical side, the look is still depending upon the HTML you produce
;) )
3 compared to 2 has the additional problems that:
- it's usually more rigid. With Zope you write your site as dynamic or
as static you like.
- While there are free CMS beside Zope, there is a number of quite
expensive CMS options.
1's disadvantages and advantages:
+ works with most "pay-for" webhosters.
- difficult to customize.
- you get a completely non-homogen mixture of technology.
(Your Guestbook remembers the User data via a different set of cookies
than your talkback section, etc.)
- you usually need some kind of database. Or you have CGI that store
data that belongs into an ACID storage in the filesystem.
2's list:
+ ZODB (Zope Object Database) is the ultimate in safe data storage.
[Actually I've tried to track any ZODB troubles by looking at the
mailing lists, and while I've found some issues, they were nothing to
write home about. Probably safer to your data than any other open
source data storage. And the safety of closed source big iron
databases is difficult to guess as they are not only closed source,
but usually also closed bug tracking, ...]
- steep learning curve.
+ Python.
+ cross platform. (Host it on Linux system, develop on Windows,
whatever)
+ ZEO (clustering solution)
+ open source.
+ easy integration with SQL databases.
So depending upon your needs and your own set of prejudices (I'm on the
free software side. So Frontpage is not really a contender IMHO), Zope
might be what you need or not.
ad Performance:
I can only give anectodal evidence because I haven't yet tried to do
more scientific benchmarking.
4 different hosts:
a) 486DX4/75, 24MB RAM, 4GB old non-dma harddisc
b) Vaio FX201, Duron 700, 512MB RAM, 10GB laptop dma IDE
c) Thunderbird 900, 768MB RAM, dma IDE
d) Celeron 600, 128MB RAM, dma IDE (older) [small webhosting server]
Zope 2.5.1 (ZServer) on a) with the standard page (which does minimal
dynamic things like including header and footer) seems to be able to
give about 3-4 requests per second.
Zope 2.6.0a1 (ZServer) on b) with some dynamic page (objectValues
enumeration, etc.) get's into about 30-35 requests per second.
Zope 2.5.1 (Apache/PCGI) on d) gets about 10-20 requests /s for some
pages containing dynamic navigation and Structured Documents. (This site
is also visible from the outside and an example for some really simple
small site: www.detox.at)
Quixote with a dynamic page (os.listdir+os.stat) and a pure CGI adapter
(Apache) on c) gives about 3 requests per second. This is only as a
reference for the performance of "typical" CGI applications.
A static page on c) gets about 100 requests/s.
So to summerize:
Usually Zope is much faster than CGI applications. (about 10x)
(Well it's probably a bit more, because the b/c hardware is not exactly
the same.)
CGI on my setup is about 33x slower than static pages.
Zope is about 3x slower than completely static pages.
Zope can run acceptably on very minimalistic hardware.
Andreas