[horde] cache question

[Paras pradhan]

Niels,

Thanks for you input. We just changed cache driver to sql. We will see
how it goes. One thing I am confused with horde right now is using of
memcache. My php loads memcache as a module . Do I still need to set
$conf[cache][params][use_memorycache] to memcache?

Thanks for any input.

Paras.

On Fri, Jan 28, 2011 at 4:08 AM, Niels Dettenbach <nd at syndicat.com> wrote:
> Am Freitag 28 Januar 2011, 00:33:28 schrieb Paras pradhan:
>> I think enabling this cache is highly recommended. Should I use file
>> or other driver? which one is recommened?
>
> hmmm,
> i did not tested horde with all of the available caching backends, but i
> assume there is no general answer which of the backends gives most "effect" as
> your expectations may differ from that of others and it depends from the
> underlying system environment too.
>
> We mainly used eAccelerator driver in the past and apache's cache mechs (i.e.
> mem cache). For different reasons we run the eAccelerator disk storage on a
> tempfs at several machines with i.e. slow storage backend (i know that
> eAccelerator offers RAM caching byself) - especially with slower SAN backends.
> As caching was removed from eAccelerator > 0.9.5 (as i.e. stated within the
> Horde admin panel) we switched over to APC (which should get into the PHP
> upstream with PHP 6).
>
> Several independent benchmarks get results i.e. that eAccelerator and Zends
> optimizer is faster then APC - but i did not see any significant difference in
> practice.
>
> The efficiency and performance of a file based cache storage highly depends
> from your storage topology / I/O-system - i.e. many SATA and/or multi-user SAN
> topologies could be act as a significant "bottleneck".
>
> If you are able to spend a lot of RAM for caching and especially if your
> storage system is "slow" or near his limits you should prefer RAM. If RAM is
> "expensive" and your storage system is able to perform a fast handling of
> concurrent read requests you may decide for file based storage.
>
> If your SQL backend runs i.e. on a significantly faster system / machine (or
> you did not have any other choice) system then your horde SQL caching might be
> the best choice.
>
> But not at least - even your operating system and OS tunings could affect the
> performance within the different caching solutions (i.e. as they often
> interfer with OS own optimization techs or OS limits).
>
> Our experiences with memcached in the past did not match our expectations
> (plus there was several security flaws in the past within memcached) - so we
> did not use it anymore. May be this is a wrong decision. One interesting part
> is that memcached could run even on another / exteral machine.
>
> So we are still interested in further experiences here.
>
>
> cheers,
>
> Niels.
>
>
> --
>
> ---
>
>  Niels Dettenbach
>  ---
>  Syndicat IT&Internet
>  http://www.syndicat.com
>  T.-Muentzer.-Str. 2, 37308 Heilbad Heiligenstadt - DE
>  ---
>  Kryptoinfo:
>  PGP public key ID 651CA20D
>  Fingerprint: 55E0 4DCD B04C 4A49 1586  88AE 54DC 4465 651C A20D
>  https://syndicat.com/pub_key.asc
>  ---
>
> --
> Horde mailing list
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: horde-unsubscribe at lists.horde.org
>
>