[horde] Memcache issue

[Michael M Slusarz]

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.

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.  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.

So I stand by my initial statement: there is no appreciable difference  
between the Horde memcache sessionhandler and the built-in memcache  
session handler.  Given the limitations of the built-in session  
handler, there is zero reason to use it.

> The argument of avoiding changing system-wide settings in php.ini is  
> moot anyway if the system is dedicated for Horde.

Disagree.  The less places you have to make changes, the easier it is  
to admin a system.

Ideally somebody should be able to install PHP via their OS package  
manager and never have to touch the default php.ini file - all  
configuration is done entirely within Horde.

michael

___________________________________
Michael Slusarz [slusarz at horde.org]