Note also that a patch like this one (against the current Zope 2
trunk, you may need to change it based on whichever version of Zope
you're using) might shed more light on where your conflict errors are
coming from:
Index: lib/python/Zope2/App/startup.py
===================================================================
--- lib/python/Zope2/App/startup.py (revision 77024)
+++ lib/python/Zope2/App/startup.py (working copy)
@@ -166,6 +166,9 @@
conflict_errors,
unresolved_conflict_errors,
startup_time)
+ from traceback import format_exception
+ msg = '\n'.join(format_exception(t, v, traceback))
+ conflict_logger.log(level, msg)
raise ZPublisher.Retry(t, v, traceback)
if t is ZPublisher.Retry:
try:
On Jun 24, 2007, at 9:31 PM, Manuel Vázquez Acosta wrote:
Let me see if I got this right:
According to ZODB.Mount.MountPoint: mount points are Zope objects
that, when traversed, accesses a different database.
Do they report themselves as the container-class defined in zope.conf?
I mean, when I traverse to /temp_folder what do I get? Is it the
MountPoint instance or the container-class instance? Where should I
look for this code?
I have "tried" faster but without any luck. I modified OFS.Application
and replaced TransientObjectContainer with
faster.SessionDataContainer, but still I had too many ConflictErrors
(didn't make any measure to compare with TransientObjectContainer).
What I have not grasped yet, is how the whole MountPoint thing works
so that /temp_folder vanishes when Zope dies. This must be a
TemporaryStorage in another DB, accessed thru the MointPoint, but I
have not found where this is done.
Thanks for your response, and best regards,
Manuel.
On 6/24/07, Chris McDonough <[EMAIL PROTECTED]> wrote:
/temp_folder is a "mount point" (see your zope.conf file).
Whether or not you put a session data container inside of a temp
folder, you may get better conflict-related performance out of
"faster", a drop-in replacement for the stock Zope sessioning
machinery... see http://www.agendaless.com/Members/tseaver/software/
faster/ (but you might not, it depends on the sessioning access
pattern). In particular "faster" is much better conflict-wise when
sessions are accessed but not changed in the course of a request.
- C
On Jun 24, 2007, at 8:19 PM, Manuel Vázquez Acosta wrote:
> Hi all,
>
> I have been digging into Session Management in Zope, because is
> causing a little overhead. We have develop a Plone Application,
which
> must respond to 30 concurrent user every 12 seconds, we have setup
> CacheFu and Squid for this.
>
> We have used OpenSTA to stress test the application.
>
> When we run the bench for a non login test, everything goes just
fine.
> But when run a bench in which a user logs in, we observe too many
> ConflictErrors, which, I thinks, slows too much the application,
> because zope retries the request 3 times.
>
> I have read /temp_folder is RAM based folder, and also that it
should
> be a MountPoint, but looking at the code and with the help of
> DocFinderTab, I have found /temp_folder is a
> Products.TemporaryFolder.SimpleTemporaryContainer, which seems
to be
> just a folder in the ZODB... This sould be this way? Does
> /temp_folder/session_data is the RAM based storage?
>
> Best regards,
> Manuel.
> _______________________________________________
> Zope maillist - Zope@zope.org
> http://mail.zope.org/mailman/listinfo/zope
> ** No cross posts or HTML encoding! **
> (Related lists - http://mail.zope.org/mailman/listinfo/zope-
announce
> http://mail.zope.org/mailman/listinfo/zope-dev )
>
_______________________________________________
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
