[Koha-devel] memcached?

[Fouts, Clay]

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.

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


On Fri, Jun 4, 2010 at 9:40 AM, Dobrica Pavlinusic <dpavlin at rot13.org>wrote:

> On Fri, Jun 04, 2010 at 04:35:51PM +0100, Colin Campbell wrote:
> > On 04/06/10 15:42, Cindy Murdock Ames wrote:
> > >Hi all,
> > >
> > >The good news: CCFLS went live with 3.2alpha2 on Tuesday! The bad news:
> > >our transactions are *really* slow at times. I suspect the culprit is
> > >probably a ton of simultaneous mysql activity.
> > Have you done any tuning of mysql? Out of the box it probably is
> > using less memory than it needs for efficient running. A lot of the
> > my.cnf parameters can be tuned to improve throughput.
> > Memcache can work wonders but it needs to be caching the data thats
> > causing you to thrash the db. I'm not sure we've reached that point
> > yet.
>
> I documented my journy over mysql tuning for Koha at:
>
> http://blog.rot13.org/2010/04/mysql_is_slow_did_you_tune_your_settings.html
>
> Just running mysqltuner.pl or tuning-primer.sh will probably be enough
> :-)
>
> I would highly recommend putting session files at filesystem as opposed
> to database, especially if you have semi-high load on your website (web
> crawlers and what not) because it cut down database load by 75% for us.
>
> Testing current memcache in Koha, it seemed to be used only for
> localization caching, and it was a bit slower on our system after some
> basic profiling. YMMV.
>
> --
> Dobrica Pavlinusic               2share!2flame
> dpavlin at rot13.org
> Unix addict. Internet consultant.
> http://www.rot13.org/~dpavlin
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20100604/f7cb2e35/attachment.htm>