[Checkins] SVN: z3c.flashmessage/trunk/src/z3c/flashmessage/README.txt Warn people about performance limitations of using ZODB storage for zope.session and z3c.flashmessage

[Paul Winkler]

Log message for revision 93062:
  Warn people about performance limitations of using ZODB storage for zope.session and z3c.flashmessage

Changed:
  U   z3c.flashmessage/trunk/src/z3c/flashmessage/README.txt

-=-
Modified: z3c.flashmessage/trunk/src/z3c/flashmessage/README.txt
===================================================================
--- z3c.flashmessage/trunk/src/z3c/flashmessage/README.txt	2008-11-17 22:36:18 UTC (rev 93061)
+++ z3c.flashmessage/trunk/src/z3c/flashmessage/README.txt	2008-11-17 23:08:49 UTC (rev 93062)
@@ -104,7 +104,32 @@
 []
 
 
+Performance and Scalability Issues
+==================================
 
+By default, messages are stored persistently in the ZODB using
+zope.session.  This can be a significant scalability problem; see
+design.txt in zope.session for more information.  You should think
+twice before using flashmessages for unauthenticated users, as this
+can easily lead to unnecessary database growth on anonymous page
+views, and conflict errors under heavy load.
+
+One solution is to configure your system to store flashmessages in
+RAM. You would do this by configuring a utility providing
+z3c.flashmessages.interfaces.IMessageSource with the factory set to
+z3c.flashmessages.sources.RAMMessageSource, and a specific name if
+your application expects one.
+
+RAM storage is much faster and removes the persistence issues
+described above, but there are two new problems.  First, be aware that
+if your server process restarts for any reason, all unread
+flashmessages will be lost.  Second, if you cluster your application
+servers using e.g. ZEO, you must also ensure that your load-balancer
+supports session affinity (so a specific client always hits the same
+back end server).  This somewhat reduces the performance benefits of
+clustering.
+
+
 Changes
 =======