http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12005
--- Comment #8 from Chris Cormack <[email protected]> --- (In reply to Jacek Ablewicz from comment #7) > (In reply to Chris Cormack from comment #6) > > > This patch changes it so plack works the same way that cgi did. > > At the moment I don't have a persistent install properly set up & suitable > for any meaningfull testing, but - at least at the 1st glance, this proposed > patch doesn't look quite right to me: > > 1) Completely abandoninig Zconn caching would have some measurable impact > (performance-wise and memory-footprint-wise) in non-persistent > installations. How significant such an impact may be in the practical > circumstances is another question - while Koha does not seem to use cached > Zconn very often, in those rare (?) cases when it does, cached Zconn is > being used rather extensivelly (eg. when performing authority searches). > It would if it was working, but the caching has never worked. It has never been doing caching, you make a connection, and use it and then cgi dies and the connection disappears. In plack you make a connection, you use it, you stop using it, you asking for a new connection, it tries to give you back the old one that is dead. Searches break. So while I agree caching would probably be good, the fact is there is no performance hit from removing it, because we never had it. > 2) Removing a code part which used to destroy() previously made zebra > connection may be not such a good idea IMO. AFAIRC (it's been several months > since I had a look at that code), previously estabilished Zconn is not being > atomatically destroyed when the variable which holds it gets udefined, goes > out of scope, etc. Unless I'm very much mistaken - with this patch applied, > when running in persistent environment - yes, Koha will indeed make brand > new zebra connection each time it does perform a search, but the problem is > that previously made connection[s] would never get destroyed (and they will > accumulate pretty quicky, eventually leading to the crash when the system > goes out of available RAM for new zebra processes, free filehandles for > subsequent connections and so on). THis is not our experience we have been running it live in production for 6 months, zebra kills the connections without the destroy -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
