I expanded by benchmark of DBD::Multi to also include DBIx::HA for
comparison.
While the benchmark reported nearly a 200% overhead for DBD::Multi,
the overhead of DBIx::HA was much better, reported at 50%.
That sounds like a lot in both cases, but is not necessarily. First, my
test case is not normal-- the SELECT statement used is incredibly
simple. Second, even the slowest one still achieved over 2,000 selects
*per second*.
Still, if both modules offer functionality that meets your needs,
why not go with higher-performance solution?
Here's my raw result:
timing 10000 iterations of ha, multi, raw...
ha: 4 wallclock secs ( 1.98 usr + 0.20 sys = 2.19 CPU) @ 4571.43/s
(n=10000)
multi: 7 wallclock secs ( 3.97 usr + 0.23 sys = 4.20 CPU) @ 2383.61/s
(n=10000)
raw: 3 wallclock secs ( 1.28 usr + 0.19 sys = 1.47 CPU) @ 6808.51/s
(n=10000)
Rate multi ha raw
multi 2384/s -- -48% -65%
ha 4571/s 92% -- -33%
raw 6809/s 186% 49% --
#############
The meat of the meat of the benchmark was essentially the following. In
each case, I made a connection to a single database:
cmpthese(10_000, {
raw => sub { $raw_dbh->selectrow_array("SELECT CURRENT_DATE") },
multi => sub { $multi_dbh->selectrow_array("SELECT CURRENT_DATE") },
ha => sub { $ha_dbh->selectrow_array("SELECT CURRENT_DATE") },
});
##############
In the process of developing this benchmark, I did find an
incompatibility with DBD::Pg, which I notified the DBD::Pg developers
about, and submitted a patch for:
http://rt.cpan.org/Ticket/Display.html?id=24503
Mark
