I have profiled `/catalogue/search.pl?q=d` (20 results, xslt) and found than at least 600ms are spent in DBIx::Class::Storage::DBI::ensure_connected, which is called 5749 times (almost 1 per query).
Created attachment 49632 [details] [review] Bug 16156: Do not ensure the dbh is connected all the time I have profiled `/catalogue/search.pl?q=d` (20 results, xslt) and found that at least 600ms are spent in DBIx::Class::Storage::DBI::ensure_connected, which is called 5749 times (almost 1 per query). Ideally we could work on the basis that the connection is only checked when a thread is started. This is what does this patch. Unfortunately this patch will revive timeout issues with long run process (SIP server for instance). Before this patch: 901398 statements and 346866 subroutine calls in 406 source files and 55 string evals spent 637ms (33.0+604) within DBIx::Class::Storage::DBI::ensure_connected which was called 5749 times, avg 111µs/call After this patch: 817161 statements and 265940 subroutine calls in 406 source files and 55 string evals spent 49.8ms (6.58+43.2) within DBIx::Class::Storage::DBI::ensure_connected which was called 343 times, avg 145µs/call
We could also imagine a 'ensure_connected' flag, not to use the $context->{dbh} even if exists, for long run processes.
And? Is this stupid? Any thoughts?
*** Bug 19819 has been marked as a duplicate of this bug. ***
I don't have time to think about this right now, but I'd do things with persistent/long running processes as the target? I figure this is one of those things that is best handled at the start of a request but I don't know. I ran into this problem with Wildfly/JBoss and this is how I dealt with it: https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/6.4/html/administration_and_configuration_guide/sect-database_connection_validation
(In reply to David Cook from comment #5) > I don't have time to think about this right now, but I'd do things with > persistent/long running processes as the target? To answer I am going to quote content from previous comments: (In reply to Jonathan Druart from comment #1) > Created attachment 49632 [details] [review] [review] > Unfortunately this patch will revive timeout issues with long run > process (SIP server for instance). (In reply to Jonathan Druart from comment #2) > We could also imagine a 'ensure_connected' flag, not to use the > $context->{dbh} even if exists, for long run processes. It is in discussion. So first "Do you think it makes sense?" then either we abandon or we go further and I continue to implement the idea. As you can see I have been waiting for "discussion" for more than 3 years now ;)
As we want to minimize ensure_connected, we probably should not add a connected test to Koha::Database like bug 20089#c2 suggested?
(In reply to Marcel de Rooy from comment #7) > As we want to minimize ensure_connected, we probably should not add a > connected test to Koha::Database like bug 20089#c2 suggested? c2 => c1
I don't think this is still valid. I am not seeing ensure_connect calls anymore (or at least way less), but I had a bit of trouble to make Nytprof working with the last ktd (?)
(In reply to Jonathan Druart from comment #9) > I don't think this is still valid. I am not seeing ensure_connect calls > anymore (or at least way less), but I had a bit of trouble to make Nytprof > working with the last ktd (?) So... can we close?