On Sun, 22 Mar 2009, Chuck Hagenbuch wrote:
Quoting Janne Peltonen <[email protected]>:
I'm not. But mm, the queries used in say, shares, use searches based on
bitwise fields etc... So if a read is going to take a couple minutes to
complete because no indices can be used because the queries are coded
against all cautions in the database server documentation, it's not much
use splitting writes anywhere else. The read takes a long time even
with no writes. (This is why everything that needs shares is mostly
disabled here.)
This is a known issue, fwiw:
http://bugs.horde.org/ticket/7363
This may be the source of some of your problems, Janne. I ran into this
problem last fall and switched back to the Datatree for shares, with some
patches to improve Datatree performance.
memcached is the perfect solution for Horde-type caching. At this point
I can say that if you are a large installation and are not using memcache
(or a similar solution) for caching, you are probably doing caching wrong
(ask Facebook - without memcache, it would not be able to run period.)
OK, another point to try. Thanks. Would this be faster than the file
based caching we're currently using? Sounds improbable, but.
Yes, memcache is definitely faster than fs-based caching if set up well.
Also, DO use memcache as your session handler. Trying to store sessions
in MySQL with Horde3 is a major performance killer.
Andy
--
IMP mailing list - Join the hunt: http://horde.org/bounties/#imp
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: [email protected]
