[Zope] performance

Casey Duncan cduncan@kaivo.com
Thu, 12 Jul 2001 08:53:20 -0600


Paul Zwarts wrote:
> 
> Greetings Zopesters,
> 
> I'm about to prepare a content system that is interface by HTML and/or
> shockwave. A list of coordinates is posted and dated records are read in
> from (the decision here) the DBMS or ZopeFolderZClass scheme plotted to
> these coords. It happens quite often and it is a multi-user system, to
> optimally executing multiplie simultaneous requests are the largest deciding
> factor.
> 
> What I am wondering is if to build my content hiearchy using Folders with
> Attributes on a ZClass schema, or Postgres records with BLOBS contianing the
> HTML. What is the performance factor?

BLOB support in Postgres is rather weak. Zope on the other-hand excels
in this area for small to medium sized files.
> 
> A) Zope is single threaded, but capable of decoupling, thus a multi-threaded
> dbms will open many threads per user. So 5 users hit the site, 5 threads are
> started and Zope will RESPOND back single-threadedly. Yes? (1 point for
> postgres)

Zope is multi-threaded and defaults to 4 active threads, which can be
changed.

> 
> B) Folder reading doesnt require anymore than Zope, thus there is less
> activity as far as dbms threading, so folder reading in per request is
> quicker, and more dependent of the servers I/O speed (U2W scsi, RAID,
> whooaa!) and the content creation model is easier to tackle to create
> objects. (1 point for Folders/Attributes/ZClasses)

Zope excels at read-intensive operations, much less-so at writing. If
performance is an issue, I would recommend not using ZClasses and
instead developing your objects as products directly in Python.

> 
> These are the two biggest pros and cons but I hope someone like Dieter and
> Chris that knows the guts of zope can advise me.

It really depends on 4 main factors in my mind, whether to use Zope or a
RDBMS:

1. What is the nature of the data itself? Zope by itself is far more
efficient dealing with BLOBS than Zope+Postgres would be. Your
implementation would be much cleaner too.
2. How do you need to query the data? Postgres has the advantage of SQL
here, Zope the text-indexing powers of ZCatalog and the straightforward
ZODB.
3. What is the read/write ratio. Postgres scales much better for
write-intensive operations.
4. What is the simplest way to implement your solution without great
compromise? If you don't have a strong reason to use an RDBMS, then
don't.
 
> Perhaps a dual-usage schema could be used. Objects are created using
> ZClasses and reside in Zope (for crawler indexing and client bookmarking,
> and no query strings) and each has its index duplicated in Zope for
> application indexing purposes. The actual Zope object wouldnt be requested
> until its page was needed, and not its presence in an index. I think that
> would be the best of both worlds. Comments, or did I just solve my own
> problem?

Again, try to find the simplest solution to your problem, but no
simpler. And remember, the most reliable, best performing and easiest
parts of your system to maintain are the parts that aren't there.

> 
> Thanks as always.
> Paz
> 

Good luck!
-- 
| Casey Duncan
| Kaivo, Inc.
| cduncan@kaivo.com
`------------------>