>
> timethese($count, {
> 'query_mem' => sub {
> my $sth = $dbh->prepare($sql);
> my @res = ();
> for (@ids) {
> my $str = $memd->get($_);
> unless ($str) {
> $sth->execute($_);
> ($str) = $sth->fetchrow_array;
> $memd->set($_, $str);
> }
>
> push @res, [$_, $str];
> }
>
> out(@res);
> }
The confusion here is probably more about you comparing the fastest
nearly-fully-C-based DB path vs the slowest possible memcached path.
Asking DBI for a simple query and then calling fetchrow_array (its fastest
deserializer) is very hard to beat.
If you're looking to see if an actual loaded DB would improve or not, you
need to make the DB queries as slow as you see in production. You might as
well reduce them to timed sleeps that roughly represent what you'd see in
prod... If your dataset really is this fast, small, single-threaded, and
in memory, there is no purpose to memcached.
> Benchmark: timing 10000 iterations of query_dbh, query_mem...
> query_dbh: 6 wallclock secs ( 3.29 usr + 1.03 sys = 4.32 CPU) @
> 2314.81/s (n=10000)
> query_mem: 54 wallclock secs (30.02 usr + 8.24 sys = 38.26 CPU) @
> 261.37/s (n=10000)
Cache::Memcached is a slowish pure-perl implementation. It helps speed
things up with very slow DB queries, or very large hot data set that won't
fit in your DB (ie; even fastish DB queries start to slow down as they hit
disk more often than not). It's also great to relieve concurrency off of
your DB.
If you're trying to compare raw speed vs speed you probably want to start
with the Memcached::libmemcached library. That's the "faster" C based guy.
There's also a wrapper to make it look more like Cache::Memcached's
interface...
-Dormando
