NYTprof combined with firebug (or chrome dev tools) can give you the comprehensive picture. The former atomizes and itemizes the server side costs. The latter details the client side, including graphs of time spent downloading vs. rendering, per file.
On Jun 5, 2010 9:38 PM, "Chris Cormack" <ch...@bigballofwax.co.nz> wrote: 2010/6/5 Fouts, Clay <cfo...@ptfs.com>: > I can also attest to the benefit of storing session data somewhere other > than in the MySQL datab... 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. Ho... 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 koha-de...@lists.koha-commun...
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
