I've been doing a bit of profiling, focussing on opac-search, as it's terribly slow at times. See: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11051 for what I've looked at so far. There's one thing I'd like some comments on. http://debian.koha-community.org/~robin/opac-search-cached/nytprof/usr-share... All the pings take 1.36 seconds, which is a huge amount. It's not helped that Context::dbh is called 1423 times, I'm working on that too (many things that are called inside a tight loop, rather than grabbing all the data you might need in one go and putting it into a hash or something.) Is there a situation where the ping is likely to be required? It'd be easy to strip it out, but are there likely to be bad effects that can't be worked around? For context, I'm profiling this on a system with a remote database so that latency shows up a bit more than it would in a typical dev environment. As that's what many production systems are using, this is not atypical. The DBI docs: http://search.cpan.org/~timb/DBI-1.623/DBI.pm#ping say "Few applications would have direct use for this method. See the specialized Apache::DBI module for one example usage" so it might be reasonable to just pull it out. Any thoughts? Also have a look at the two other patches: one illustrating that caching actually slows things down some times, and the other just changing a query repeated once per branch, to just run once. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF