Connection caching does work for most use cases - we have to accept James
works in scenarios most developers can't fathom :)
If you are just firing off simple SQL's without any triggers or named
temporary tables involved you should be good. The only times we recall
tripping on cached connection is when two different code snippets tried to
create the same temporary table. Another time the code was expecting the
disconnect to complete the connection cleanup.
On Tue, Feb 9, 2021 at 11:47 AM Vincent Veyron <vv.li...@wanadoo.fr> wrote:
> On Sun, 7 Feb 2021 20:21:34 +0000
> James Smith <j...@sanger.ac.uk> wrote:
>
> Hi James,
>
> > DBI sharing doesn't really gain you much - and can actually lead you
> into a whole world of pain. It isn't actually worth turning it on at all.
> >
>
> Never had a problem with it myself in years of using it, but I wrap my
> queries in an eval { } and check $@, so that the scripts are not left
> hanging; also I have a postgresql db ;-).
>
> I ran some tests with ab, I do see an improvement in response speed :
>
> my $dbh = DBI->connect()
> Concurrency Level: 5
> Time taken for tests: 22.198 seconds
> Complete requests: 1000
> Failed requests: 0
> Total transferred: 8435000 bytes
> HTML transferred: 8176000 bytes
> Requests per second: 45.05 [#/sec] (mean)
> Time per request: 110.990 [ms] (mean)
> Time per request: 22.198 [ms] (mean, across all concurrent requests)
> Transfer rate: 371.08 [Kbytes/sec] received
>
> my $dbh = DBI->connect_cached()
> Concurrency Level: 5
> Time taken for tests: 15.133 seconds
> Complete requests: 1000
> Failed requests: 0
> Total transferred: 8435000 bytes
> HTML transferred: 8176000 bytes
> Requests per second: 66.08 [#/sec] (mean)
> Time per request: 75.664 [ms] (mean)
> Time per request: 15.133 [ms] (mean, across all concurrent requests)
> Transfer rate: 544.33 [Kbytes/sec] received
>
>
> --
>
> Bien à vous, Vincent Veyron
>
> https://compta.libremen.com
> Logiciel libre de comptabilité générale en partie double
>
>
>
>
