Hi All,

I've recently been looking at memcached for use in a project here -
I've looked at the site, read the FAQ, and whatnot - but still have a
couple of questions...

At this point in the project - we need to cache reads to a MySQL
server. I'm faced with a choice of either writing our own caching
layer - or going with memcached.

The system has a number of front end machines, which at the moment all
query a single back end MySQL server. The machines are predominately
doing read queries, and largely for the same data (i.e. Machine 'A'
will query for 'x' - Machine 'B' is then also likely to query the same
'x' - and that same query may get run a few hundred to a few thousand
times in a row).

Most of the queries are relatively 'cheap' on the SQL side - a few are
quite expensive. At this stage we're more concerned with the volume of
queries (several hundred a second) and would rather see the SQL server
just handling predominately writes.

This kind of tips the balance in favour of memcached (as our own
caching layer won't spread between machines).

My only concern is the queries we're dealing with generate tiny result
sets. Sometimes it's literally a query that returns a single 'true/
false' value, other times, it's queries that return a couple of
hundred bytes - max.

Whilst I realise, running this through memcached will 'work' (and
alleviate the load on the MySQL server for repetative reads) - I'm not
sure how 'efficient' it's going to be?

In this case do you think/guesstimate we'd be better with local
application caching - or is the overhead on memcached sufficiently
small that using it for tiny data sets is worth while? (considering
it'll 'spread' the cache between machines - which ours won't).

-Jon

Reply via email to