[Tickets #13231] listEvents will run sequentially when listing calendar events

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/13231
------------------------------------------------------------------------------
  Ticket             | 13231
  Created By         | arjen+horde at de-korte.org
  Summary            | listEvents will run sequentially when listing calendar
                     | events
  Queue              | Kronolith
  Version            | 4.1.5
  Type               | Enhancement
  State              | New
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


arjen+horde at de-korte.org (2014-05-28 06:56) wrote:

I'm using Firefox 29 which, like most browsers, will allow a limited  
number of simultaneous connections to the same server (in this  
version, six). When listing the events for my calendar, it will fire  
off 15 processes, each handling a single calendar resource. It will  
run 6 processes in parallel, so far so good.

Now the hairy part. With the builtin-, File- and Sql-sessionhandlers  
these 6 processes will run concurrently and all 15 are handled in  
about half a second. Very acceptable performance and switching between  
month views is pretty much instantaneous.

With the Hashtable sessionhandler things are quite different. Each  
process will attempt to get a lock on the (same) session data that is  
stored during session_start(). Obviously, only one of 6 listEvents  
calls succeeds to get the lock (so the locking mechanism works), the  
others have to wait until the session is closed again. So effectively,  
the listEvents calls are handled sequentially for the Hashtable  
sessionhandler. This means that switching between month views takes  
well over two seconds. Not impressive at all.

As far as I can see, the listEvents call from the Calendar will not  
have to change the session data. In this case, it might be useful to  
open the session data readonly, in which case no locking is used (nor  
needed), so multiple processes can use the same data concurrently.