Memcached vs SQL Server cache

Question

I\'ve been reading a lot of articles that suggest putting a Memcached (or Velocity, etc) in front of a database is more efficient than hitting the database directly. It wil

Answer 1

So if SQL Server has it's own cache, what is the benefit of an external Memcached (or similar) server?

Yes SQL Server has its own cache but he caches only:
- Query plans
- pages from the database files

but he does NOT cache:
- results from a query

e.g. you have a complex query which uses some aggregation on a lot of data ( think of: how many different countries we have in our customer database : SELECT DISTINCT Country from Customers GROUP BY country )

SQL Server will scan th WHOLE customer table, but your resultset will only a few entries long. When you reissue your query, SQL Server will reuse the query plan and will rescan the customer table, ( and if you are lucky the pages are still in memory )

When you use memcached you may store the few rows of your resultset and reuse them over and over again without connecting to the database server. So it takes some load from your database server.
NOTE: Beware of some stale data, if your data changes on the SQL server !!

Answer 2

Another benefit can also be that SQL Server is expensive to scale whereas adding a new web/caching server can be cheaper to achieve.

We use caching at an application level to store all sorts of things, not all of them from a database either. You may manipulate data objects in your code then add to cache for instance.

You can even store markup if necessary (output caching).

In one day by using caching we moved our site from being able to handle 150 concurrent session while stress testing to well over 800. I strongly recommend using it!!

Answer 3

Velocity, et al, are GREAT especially when your SQL server lives on its own box. We've been using ASP.NET's built-in caching but hope to move to Velocity. Several web servers talk to a SQL cluster and the caching really helps with scalability and reducing the SQL load.