One big Zope or many small Zopes? Or perhaps a ZEO?
We ( a newspaper site) are currently running several different Zope installations for different vertical products--one install for our Homes Listings, for instance, and another for our big news content site, and a couple of testing and development installs. The sites share many of the same elements--both look-and-feel stuff as well as various navigation methods, etc. Does it make sense for us to combine all of these sites into one installation so we can centralize the shared site elements, or should we keep multiple sites for performance's sake? We're weighing the issues of doing some sort of XML-RPC resource sharing or just lumping everything together under one domain and one Zope installation. Also, we're running at traffic somewhere around 60,000-80,000 page views a day--not huge traffic, but more than we had a year ago, certainly. At what traffic point have most folks noticed a need for more server power? Is it 100,000 page views? More? Less? We are also serving ads to the Zopes from a different Windows 2000 server running Apache and using a PERL process to serve the ads at a rate of between 400,000 and 700,000 ads per day. We've got a pretty Zopish site--lots of method calls, lots of ZSQL (connected to MySQL), lots of graphics and buttons all in Zope and reliance on the Catalog for index building and such. We're on a single non-Zeo install for our "big site" right now on a Win2k box, and we're having some slowness issues cropping up at times. We've had some bigger Windows/Zope/Apache problems in the past, so we're already preparing for a move to Linux (plus that seems to be where most of the community and certainly where Zope Corp. is focusing--though I'm a big fan of MacZope, personally...) We're wondering whether we should be considering a ZEO move at this time, too. And now would be a good time for us to combine our "satellite sites" under one umbrella. Any opinions? Many probably think "just ZEO it" but we would like single box alternatives also. Thanks! Chris and the gang at fredericksburg.com cmuldrow@fredericksburg.com
At 2001-10-19T16:22:27Z, Chris Muldrow <muldrow@mac.com> writes:
Also, we're running at traffic somewhere around 60,000-80,000 page views a day--not huge traffic, but more than we had a year ago, certainly. At what traffic point have most folks noticed a need for more server power? Is it 100,000 page views? More? Less?
We are also serving ads to the Zopes from a different Windows 2000 server running Apache and using a PERL process to serve the ads at a rate of between 400,000 and 700,000 ads per day.
Note: I'm a Zope newbie, as anyone reading my last week's worth of postings can tell, but I'm not completely inexperienced at network design. I would strongly recommend the use of a proxy/cache in front of your servers. It sounds as if much of your content is pseudo-static. That is, although it may change, it's likely to do so slowly. Caching servers can make a vast difference in performance in setups like this. For example, suppose that users often go to: http://mynewspaper.com/sports/todays_headlines Why force your Zope to regenerate that page 30,000 times per day when it may only change 3 or 4 times? Zope even has built-in methods for cache management so that you can have it send special headers to the cache servers to tell them how often to re-query specific objects. You may not want to cache a stock ticker at all. OTOH, the current temperature won't drastically change in any given 5 minute interval. I haven't personally used these methods yet (see the first line of my post), but I *can* certify that a properly-configured Squid server can increase your current platform's potential throughput by several hundred percent. -- Kirk Strauser
participants (2)
-
Chris Muldrow -
Kirk Strauser