[horde] Memcache issue
Arjen de Korte
arjen+horde at de-korte.org
Sun May 25 09:43:56 UTC 2014
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
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...
Size: 5849 bytes
Desc: S/MIME Signature
More information about the horde