Question

I have webservice(WCF) and MembershipProvider/RoleProvider to check credentials.

When service called – various methods call providers to get user, get login name by Id, get Id by login name and so on. End result – When looking in Profiler – I can see lot of chat.

I can easily incorporate caching into MembershipProvider and RoleProvider’s so it will cache user’s and won’t hit DB every time.

User list is not big. I don’t think it will ever be more than 100-200.

On one hand – I know SQL Server does cache small tables and designed to take care of those selects. OTOH – I SEE it in profiler 🙂 And memory on web server side will be occupied. Plus, lookups on web server still need to be done (CPU/Memory).

I guess I want to hear about your experience and should I even worry about this stuff? I placed tags “strategically” so hopefully both DBA and developers will give me some input 🙂

Answer 1

Absolutely, avoiding a round trip to the DB server pays off. Is not only the memory cache issue. Running a query, even a trivial one, is quite a complex process:

• the connection has to be opened and authenticated. It gets amortized with connection pooling, true, but even a pooled connection still requires one extra roundtrip for sp_reset_connection at open time.
• request has to be composed and sent to the server
• a task needs to be allocated for the request and a worker has to pick up the task. workers are very precious resource in SQL Server, as there are so few of them.
• SQL has to parse your query. At the very very best it can skip the parsing but still needs to hash the input text, see Dynamically created SQL vs Parameters in SQL Server
• query has to be executed, locks acquired, pages in memory looked up. Locking is especially expensive because it may conflict with other operation and has to wait. Using snapshot isolation can help to some (large) extent.
• the result has to be marshaled back to client.
• client has to parse the response metadata.
• client has to process the response.

An local in memory lookup will win most times. Even a remote cache lookup like memcached will win over a DB query, no matter how trivial the query. So why not always cache locally? Because of the one of the most hard problems in CS: cache coherency and invalidation. It is a problem that is way harder than you think it is right now, no matter how hard you think it is ;). You may look at SQL Server’s own active cache invalidation solution, Query Notifications, which works pretty well for fairly static result sets. I have a LINQ integration with Query Notification project myself, LinqToCache.