[horde] Memcache issue

[Arjen de Korte]

Citeren Michael M Slusarz <slusarz at horde.org>:

> Quoting Arjen de Korte <arjen+horde at de-korte.org>:
>
>> Citeren Michael M Slusarz <slusarz at horde.org>:
>>
>>> Quoting Arjen de Korte <arjen+horde at de-korte.org>:
>>>
>>>> Citeren Administrator BCS <adje at bezoekerscentrumsonsbeek.nl>:
>>>>
>>>>> Got Horde is up and running but performance is not what it  
>>>>> should be. It seems I have a problem with memcache. Memcache is  
>>>>> up and running, I can connect to it with telnet localhost 11211,  
>>>>> but the stats tells me nothing is happening there.
>>>>
>>>> First question, how many concurrent users do you have? If there  
>>>> is a performance issue, installing memcache is not magically  
>>>> going to fix that for you. In you case it might help only if you  
>>>> have a problem with storing/retrieving session information, but  
>>>> that will happen only if you have many concurrent users and are  
>>>> starved on I/O. And even then using native memcache sessions  
>>>> might be preferred over using a distributed hashtable for caching  
>>>> session information.
>>>
>>> There is no appreciable performance difference between the two on  
>>> a modern system, with the advantage that Horde_Sessionhandler  
>>> sessions allow things like large session data and statistics and  
>>> also doesn't require you to change system-wide settings in your  
>>> php.ini file (which should be avoided as much as possible).
>>
>> Well, maybe my system lacks the proper horsepower needed for the  
>> above to be true, but what I see here is that using the hashtable  
>> session handler requires about twice the time to switch between  
>> month views in Kronolith compared to native memcache (in php.ini).
>
> I can safely say that either your system is misconfigured or  
> something else is causing the delay.

There is not much to configure for the Hashtable sessionhandler as far  
as I can see. Given that native memcache sessions are as fast as  
pretty much any other sessionhandler, I have to assume that there is  
something in the Hashtable sessionhandler that causes this. Memcache  
is running on localhost with 4 threads. Could it be this is not enough?

> Using xdebug to profile a system that is using the Hashtable session  
> storage with memcache (single memcache server located on a different  
> machine - albeit a VM - then the Horde box), and loading a page.
>
> Looking at session_start() - where the actual  
> retrieval/decompression of the session data occurs from the backend  
> - total cumulative time in that method is 2.7ms.

I checked session_start() for the Sql (~10 ms) and the Hashtable (~1.1  
ms) sessionhandlers, no surprises here.

> This particular page, initial load of IMP dynamic mailbox page, had  
> a total run-time of 395ms. Thus, session retrieval accounts for less  
> than 1% of the total time to load the
> page.  Even assuming that the built-in memcache sessionhandler has a  
> run-time of 0ms (it doesn't), you are saving all of ~3ms, which is  
> irrelevant.  Optimizing a single extra/superfluous IMAP call -  
> something I did yesterday for example - is much more  
> performance-relevant.

Except I wasn't talking about loading IMP. There is no appreciable  
difference between *any* session handler I tried (including file based  
and hashtable) when using IMP. Pretty much everything is handled in  
under 100 ms, which is well below what is noticeable.

I specifically mentioned I was changing from one month view to the  
next (May -> June for instance) in Kronolith. The difference between  
IMP and Kronolith in this aspect is that IMP is just one request for  
most (if not all) operations, while Kronolith will fire off about 15  
processes, each handling a different calendar resource (I have a bunch  
of shared calendars, weather & other stuff in my calendar). I'm using  
Firefox 29 for testing, which defaults to running 6 simultaneous  
requests per server. Looking at the xdebug output, I see that the  
Hashtable session handler spends most of its time in php::usleep(),  
waiting for Horde_Memcache->lock to complete (up to 2 seconds). In  
contrast, both Sql sessionhandler and native memcache sessions still  
show pretty much the same time for session_start() as before with IMP.
-- 
This message was sent from a mailinglist subscription address.
For off-list replies, you must remove the address extension.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5849 bytes
Desc: S/MIME Signature
URL: <http://lists.horde.org/archives/horde/attachments/20140525/7a668a2f/attachment.bin>