[Tickets #13231] Re: Hashtable session handler doesn't unlock on session close
noreply at bugs.horde.org
noreply at bugs.horde.org
Thu May 29 10:01:51 UTC 2014
DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.
Ticket URL: http://bugs.horde.org/ticket/13231
------------------------------------------------------------------------------
Ticket | 13231
Updated By | arjen+horde at de-korte.org
Summary | Hashtable session handler doesn't unlock on session
| close
Queue | Horde Framework Packages
Version | Git master
Type | Bug
State | Feedback
Priority | 1. Low
Milestone |
Patch |
Owners |
+New Attachment | Horde_Memcache.patch
------------------------------------------------------------------------------
arjen+horde at de-korte.org (2014-05-29 10:01) wrote:
> Lowering the poll delay is not a viable option. At 10 polls/second
> (per request), that is already quite a bit of network/protocol
> overhead.
>
> Maybe it would be better to implement a logarithmically increasing
> delay mechanism. Or for true performance, a hybrid flock/memcache
> system.
After session_start(), it seems to take a few milliseconds before the
lock on the session data is released. I noticed that frequently it
takes a while before the first six listEvents that are started manage
to start a session. This is due to the fact that the poll delay for
all of them is identical, so if they are started at the same time, the
subsequent polls to retry to get a lock on the session data will also
coincide. In that case, it may take up to six times 100 ms before all
processes get going. Adding some randomness in the polling would help
to minimize that, by retrying at different intervals (see attached
patch).
arjen+horde at de-korte.org (2014-05-29 10:01) uploaded: Horde_Memcache.patch
http://bugs.horde.org/h/services/download/?app=whups&actionID=download_file&file=Horde_Memcache.patch&ticket=13231&fn=%2FHorde_Memcache.patch
More information about the bugs
mailing list