2010/6/5 Fouts, Clay <[email protected]>: > 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 _______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
