Personal tools
Skip to content. | Skip to navigation
Zope Object Database
The ZODB3 distribution is a “meta” distribution that requires projects: ZODB, persistent, BTrees and ZEO, which, in the past, were included in the ZODB 3 project. For more information on ZODB, persistent, BTrees, and ZEO, see the respective project pages in PyPI:
ZODB development header files
Backport publication events from Zope 2.12 ZPublisher to Zope 2.10
Zope 2 ZServer.
This package is used to support the Prefix object that Zope 2 uses for the undo log. It is a separate package only to aid configuration management. This package is included in Zope 2. It can be used in a ZEO server to allow it to support Zope 2’s undo log , without pulling in all of Zope 2.
$ checkinterval 1305 The number you see is the recommended check interval for this machine; put it into your zope.conf file: python-check-interval 1305 Now restart Zope and bask in the glow. Why care? The Python Library Reference on the topic of check interval: "This integer value determines how often the interpreter checks for periodic things such as thread switches and signal handlers. The default is 100, meaning the check is performed every 100 Python virtual instructions. Setting it to a larger value may increase performance for programs using threads." Now, the Zope application server is such a program, and it benefits greatly from setting the right check interval. If the value is too low, Zope threads are interrupted unnecessarily, causing a noticable performance hit on today's multi-cpu hardware. Where's the 50 coming from? The constant 50 in the formula was determined by benchmarks performed at Zope Corporation and has become part of the "Zope lore" (See e.g. this post by Matt Kromer). Going beyond pystone/50 produced no further benefits. The value may well be meaningless for applications other than Zope and platforms other than Intel. Background More on check intervals and the GIL from David Beazly. For those back from the Beazly talk: Zope uses long running threads and asyncore, making it (more) independent from OS scheduling issues. Still, the interruption argument holds.