[horde] Memcache issue
Michael M Slusarz
slusarz at horde.org
Fri May 23 20:15:34 UTC 2014
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
>> 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
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 Slusarz [slusarz at horde.org]
More information about the horde