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

* Your Email Address
* Spam protection	Enter the letters below: .__ . .. ..___..___. [__)\| \|\|\ \| \| \| \| \\|__\|\| \\| \| \|
Comment	>> This doesn't help. As I noted above, 10 requests/second is already >> fairly heavy usage. Your solution bumps that up to 20 >> requests/second (you have to assume worst-case scenario). > > No, you don't. The requests will follow a Poisson distribution, > assuming mt_rand is not biased towards certain values. So the with > increasing number of requests, the average will quickly stabilise > towards 10 requests/second. > >> And there is a general (albeit not mandatory) requirement that >> requests SHOULD be handled in a FIFO basis. If Kronolith for some >> reason sends 15 listEvents requests in a row, it is a reasonable >> assumption that the 15th is the least important request. It should >> not, by virtue of random luck, suddenly jump to 2nd in the queue. > > There is no way (whatever method you use) if these requests are > handled by separate processes and it is required to get a lock on a > shared resource. If that is needed, a new request can only be > initiated when the previous one is know to be active (not waiting to > get a lock on a resource). Since this is not done, requests can (and > will be) served in random order. As the cachegrind output I sent you > also indicates, where the third request that was started is served > last.
Attachment
Watch this ticket