As far as multiprocessing goes, if I were to run a MySQL database on the same server (serving primarily to Zope) then the multiprocessor config would be a very big performance boost wouldn't it? What about Memory? Again with MySQL. I suppose I should have mentioned it right of. Our main goal is to serve up pages from a database that will be about 500MB-1GB in size. There will be very little information which will be cachable, almost all of the queries are unique. Johan Carlsson wrote:
Beyond that, what do you suggest. Is memory more important than processor speed? Is it important to go with a Multi-processor server or will Zope/Linux take advantage of a multi processor setup?
Zope, more correctly Python will not take advantage of a dual processor.
Yes it will, it just won't scale exactly two fold. In almost all Python wrapped C calls, the C code releases the interpeter lock as often as possible, this allways happens, for example, when doing I/O or when calling database library routines. Two processors will give you a noticable benefit. Four or more will probably not. Further, Zope will not be the only process running, so a dual gives you the usual benefits, like doing a compile on one thing without killing your website.
I probably seriously consider buying a ZEO solution from DC. I don't know, but a ZEO solution might solve the problem with 100 continuous concurrent users writing to the ZODB?
ZODB FileStorage was not designed to be write intensive, the goal is to provide a mid-write high-read solution, this solution satisfies 99.9% of all web site needs. You would be surprised how much money you have to pay to Oracle to get, for example, their high write-write distributed database solutions (its in the six figures). ZEO is a distributed storage, but in the end it depends on a mechanism that actual writes the data somewhere. In the stock case, this is a FileStorage. If you want high-write intensity, consider a BerkeleyStorage (which works fine as the backend for ZEO) or offload alot of your high-write intensive data to a relational database. -Michel