[Koha-devel] memcached?

[Chris Cormack]

2010/6/5 Fouts, Clay <cfouts at ptfs.com>:
> I can also attest to the benefit of storing session data somewhere other
> than in the MySQL database. LLEK has the ability to store its session data
> through memcached instead of writing to a file (which can create problems in
> a multi-server configuration) or MySQL. This frees up the database more than
> one might expect. The constant stream of tiny, non-contiguous INSERTs and
> UPDATEs contributes heavily to fragmentation of InnoDB writes which in turn
> lengthens transaction times. (Not to mention Koha's inability to selectively
> cull stale sessions, causing your table to have millions of rows over time).
> The drawback is of course that if memcached goes away you lose all your
> current session data since it's not a permanent storage medium, but this is
> not a significant loss in most circumstances.

Storing as temp files on a ram based disk as has already been
suggested works much the same way too. Of course a patch for using
memcached for session storage would be gratefully accepted and would
save on once again doubling up on work already done.

We use memcached to a huge extent at work, including storing session
data, and have yet to have any real problems occur.

> The MySQL "slow query" log is also very valuable for tracking down queries
> that hog DB time. However, the single most effective tool I've seen for
> finding performance bottlenecks is the NYTProf execution profiler. It can be
> a bit cumbersome to use, but the results give crystal clear insight into
> which functions are taking up the most time (though it doesn't necessarily
> give information about why they take up so much time). I have been surprised
> at how often MySQL is *not* to blame when it comes to Koha's performance.
> Clay
>
I concur, MySQL is usually not the bottleneck, unless the site is
under extreme load, the startup cost of perl is a major factor, as
Mason has suggested mysql, zebra and in fact apache2 can fight each
other for I/O and CPU. Different partitions/disks for mysql and zebra
can provide an easy win.

One thing that the Profiler won't tell you, is how fast your browser
can render the pages, Koha 3.2 (and 3.0) before it have a lot more css
and js on the intranet that previous versions. Different browsers can
render the page quite a bit faster, also the expires headers suggested
by Mason will stop the browser refetching things that it doesn' t need
too.

We found at HLT with the new site, that using Chrome instead of
Firefox on the circ desk provided a 2-3 second speed up in page
render.  Something worth trying.


Chris