[Zodb-checkins] CVS: ZODB3/ZEO - ClientStorage.py:1.93.2.5
README.txt:1.4.30.1 StorageServer.py:1.92.10.5 runzeo.py:1.12.10.2
Jeremy Hylton
jeremy at zope.com
Thu May 29 13:28:24 EDT 2003
Update of /cvs-repository/ZODB3/ZEO
In directory cvs.zope.org:/tmp/cvs-serv12880/ZEO
Modified Files:
Tag: ZODB3-auth-branch
ClientStorage.py README.txt StorageServer.py runzeo.py
Log Message:
Merge trunk to auth branch.
Need to move the _handle_extensions() call in notifyConnected() to
work with authentication.
=== ZODB3/ZEO/ClientStorage.py 1.93.2.4 => 1.93.2.5 ===
--- ZODB3/ZEO/ClientStorage.py:1.93.2.4 Wed May 28 14:37:32 2003
+++ ZODB3/ZEO/ClientStorage.py Thu May 29 12:27:53 2003
@@ -466,6 +466,11 @@
if not conn.is_async():
log2(INFO, "Waiting for cache verification to finish")
self._wait_sync()
+ self._handle_extensions()
+
+ def _handle_extensions(self):
+ for name in self.getExtensionMethods():
+ setattr(self, name, self._server.extensionMethod(name))
def set_server_addr(self, addr):
# Normalize server address and convert to string
@@ -594,7 +599,7 @@
Dictionary values should be None; this will be a handy place
for extra marshalling information, should we need it
"""
- return self._info['extensionMethods']
+ return self._info.get('extensionMethods', {})
def supportsUndo(self):
"""Storage API: return whether we support undo."""
@@ -665,12 +670,6 @@
"""
return self._server.history(oid, version, length)
- def __getattr__(self, name):
- if self.getExtensionMethods().has_key(name):
- return self._server.extensionMethod(name)
- else:
- raise AttributeError(name)
-
def loadSerial(self, oid, serial):
"""Storage API: load a historical revision of an object."""
return self._server.loadSerial(oid, serial)
@@ -803,7 +802,6 @@
self._tbuf.clear()
self._seriald.clear()
del self._serials[:]
- self._tbuf.clear()
def end_transaction(self):
"""Internal helper to end a transaction."""
=== ZODB3/ZEO/README.txt 1.4 => 1.4.30.1 ===
--- ZODB3/ZEO/README.txt:1.4 Thu Nov 21 13:55:27 2002
+++ ZODB3/ZEO/README.txt Thu May 29 12:27:53 2003
@@ -3,7 +3,7 @@
=======
What's ZEO?
-===========
+-----------
ZEO stands for Zope Enterprise Objects. ZEO is an add-on for Zope
that allows a multiple processes to connect to a single ZODB storage.
@@ -15,13 +15,12 @@
directory (ZEO1). Some documentation for ZEO is available in the ZODB
3 package in the Doc subdirectory. ZEO depends on the ZODB software;
it can be used with the version of ZODB distributed with Zope 2.5.1 or
-later. More information about ZEO can be found on its home on the
-web:
+later. More information about ZEO can be found in the ZODB Wiki:
- http://www.zope.org/Products/ZEO/
+ http://www.zope.org/Wikis/ZODB
What's here?
-============
+------------
This list of filenames is mostly for ZEO developers::
@@ -43,129 +42,3 @@
version.txt text file indicating the ZEO version
zrpc/ subpackage implementing Remote Procedure Call (RPC)
-Client Cache Tracing
-====================
-
-An important question for ZEO users is: how large should the ZEO
-client cache be? ZEO 2 (as of ZEO 2.0b2) has a new feature that lets
-you collect a trace of cache activity and tools to analyze this trace,
-enabling you to make an informed decision about the cache size.
-
-Don't confuse the ZEO client cache with the Zope object cache. The
-ZEO client cache is only used when an object is not in the Zope object
-cache; the ZEO client cache avoids roundtrips to the ZEO server.
-
-Enabling Cache Tracing
-----------------------
-
-To enable cache tracing, set the environment variable ZEO_CACHE_TRACE
-to the name of a file to which the ZEO client process can write. ZEO
-will append a hyphen and the storage name to the filename, to
-distinguish different storages. If the file doesn't exist, the ZEO
-will try to create it. If there are problems with the file, a log
-message is written to the standard Zope log file. To start or stop
-tracing, the ZEO client process (typically a Zope application server)
-must be restarted.
-
-The trace file can grow pretty quickly; on a moderately loaded server,
-we observed it growing by 5 MB per hour. The file consists of binary
-records, each 24 bytes long; a detailed description of the record
-lay-out is given in stats.py. No sensitive data is logged.
-
-Analyzing a Cache Trace
------------------------
-
-The stats.py command-line tool is the first-line tool to analyze a
-cache trace. Its default output consists of two parts: a one-line
-summary of essential statistics for each segment of 15 minutes,
-interspersed with lines indicating client restarts and "cache flip
-events" (more about those later), followed by a more detailed summary
-of overall statistics.
-
-The most important statistic is probably the "hit rate", a percentage
-indicating how many requests to load an object could be satisfied from
-the cache. Hit rates around 70% are good. 90% is probably close to
-the theoretical maximum. If you see a hit rate under 60% you can
-probably improve the cache performance (and hence your Zope
-application server's performance) by increasing the ZEO cache size.
-This is normally configured using the cache_size keyword argument to
-the ClientStorage() constructor in your custom_zodb.py file. The
-default cache size is 20 MB.
-
-The stats.py tool shows its command line syntax when invoked without
-arguments. The tracefile argument can be a gzipped file if it has a
-.gz extension. It will read from stdin (assuming uncompressed data)
-if the tracefile argument is '-'.
-
-Simulating Different Cache Sizes
---------------------------------
-
-Based on a cache trace file, you can make a prediction of how well the
-cache might do with a different cache size. The simul.py tool runs an
-accurate simulation of the ZEO client cache implementation based upon
-the events read from a trace file. A new simulation is started each
-time the trace file records a client restart event; if a trace file
-contains more than one restart event, a separate line is printed for
-each simulation, and line with overall statistics is added at the end.
-
-Example, assuming the trace file is in /tmp/cachetrace.log::
-
- $ python simul.py -s 100 /tmp/cachetrace.log
- START TIME DURATION LOADS HITS INVALS WRITES FLIPS HITRATE
- Sep 4 11:59 38:01 59833 40473 257 20 2 67.6%
- $
-
-This shows that with a 100 MB cache size, the cache hit rate is
-67.6%. So let's try this again with a 200 MB cache size::
-
- $ python simul.py -s 200 /tmp/cachetrace.log
- START TIME DURATION LOADS HITS INVALS WRITES FLIPS HITRATE
- Sep 4 11:59 38:01 59833 40921 258 20 1 68.4%
- $
-
-This showed hardly any improvement. So let's try a 300 MB cache
-size::
-
- $ python2.0 simul.py -s 300 /tmp/cachetrace.log
- ZEOCacheSimulation, cache size 300,000,000 bytes
- START TIME DURATION LOADS HITS INVALS WRITES FLIPS HITRATE
- Sep 4 11:59 38:01 59833 40921 258 20 0 68.4%
- $
-
-This shows that for this particular trace file, the maximum attainable
-hit rate is 68.4%. This is probably caused by the fact that nearly a
-third of the objects mentioned in the trace were loaded only once --
-the cache only helps if an object is loaded more than once.
-
-The simul.py tool also supports simulating different cache
-strategies. Since none of these are implemented, these are not
-further documented here.
-
-Cache Flips
------------
-
-The cache uses two files, which are managed as follows:
-
- - Data are written to file 0 until file 0 exceeds limit/2 in size.
-
- - Data are written to file 1 until file 1 exceeds limit/2 in size.
-
- - File 0 is truncated to size 0 (or deleted and recreated).
-
- - Data are written to file 0 until file 0 exceeds limit/2 in size.
-
- - File 1 is truncated to size 0 (or deleted and recreated).
-
- - Data are written to file 1 until file 1 exceeds limit/2 in size.
-
-and so on.
-
-A switch from file 0 to file 1 is called a "cache flip". At all cache
-flips except the first, half of the cache contents is wiped out. This
-affects cache performance. How badly this impact is can be seen from
-the per-15-minutes summaries printed by stats.py. The -i option lets
-you choose a smaller summary interval which shows the impact more
-acutely.
-
-The simul.py tool shows the number of cache flips in the FLIPS column.
-If you see more than one flip per hour the cache may be too small.
=== ZODB3/ZEO/StorageServer.py 1.92.10.4 => 1.92.10.5 ===
--- ZODB3/ZEO/StorageServer.py:1.92.10.4 Wed May 28 14:37:32 2003
+++ ZODB3/ZEO/StorageServer.py Thu May 29 12:27:53 2003
@@ -161,14 +161,15 @@
def _check_tid(self, tid, exc=None):
if self.read_only:
raise ReadOnlyError()
- caller = sys._getframe().f_back.f_code.co_name
if self.transaction is None:
+ caller = sys._getframe().f_back.f_code.co_name
self.log("no current transaction: %s()" % caller, zLOG.PROBLEM)
if exc is not None:
raise exc(None, tid)
else:
return 0
if self.transaction.id != tid:
+ caller = sys._getframe().f_back.f_code.co_name
self.log("%s(%s) invalid; current transaction = %s" %
(caller, repr(tid), repr(self.transaction.id)),
zLOG.PROBLEM)
@@ -609,8 +610,7 @@
transaction_timeout=None,
monitor_address=None,
auth_protocol=None,
- auth_filename=None,
- realm=None):
+ auth_filename=None):
"""StorageServer constructor.
This is typically invoked from the start.py script.
@@ -683,7 +683,6 @@
self.read_only = read_only
self.auth_protocol = auth_protocol
self.auth_filename = auth_filename
- self.realm = realm
self.database = None
if auth_protocol:
self._setup_auth(auth_protocol)
=== ZODB3/ZEO/runzeo.py 1.12.10.1 => 1.12.10.2 ===
--- ZODB3/ZEO/runzeo.py:1.12.10.1 Tue Apr 29 16:02:54 2003
+++ ZODB3/ZEO/runzeo.py Thu May 29 12:27:53 2003
@@ -89,9 +89,10 @@
"t:", "timeout=", float)
self.add("monitor_address", "zeo.monitor_address", "m:", "monitor=",
self.handle_monitor_address)
- self.add('auth_protocol', 'zeo.auth_protocol', None,
+ self.add('auth_protocol', 'zeo.authentication_protocol', None,
'auth-protocol=', default=None)
- self.add('auth_filename', 'zeo.auth_filename', None, 'auth-filename=')
+ self.add('auth_filename', 'zeo.authentication_database', None,
+ 'auth-filename=')
class ZEOOptions(ZDOptions, ZEOOptionsMixin):
More information about the Zodb-checkins
mailing list