Tickets :: Comment on [#13231] Hashtable session handler doesn't unlock on session close

* Your Email Address
* Spam protection	Enter the letters below: .___..__ . .._.. . _/ [__)\| \| \| \|\/\| ./__.\| \\|__\|_\|_\| \|
Comment	>> 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).
Attachment
Watch this ticket