Performance for CRM – Why not Cache?

I just attended an interactive discussion at Convergence on Archiving and best practices. Though the topic was mainly on archiving, several people talked about performance especially related to the SQL database. Also many of them compared CRM with SharePoint (MOSS 2007) and sought out differences.

Though SharePoint usually has a monstrous database storing all of the documents, the performance of the product is usually great because of one great feature in SharePoint(since MOSS 2007) . Whenever a request comes in from the user, the SharePoint front-end server requests the document from database and then caches it. For repeated requests, the front-end server serves the data from the cache instead of going to the database again. This largely reduces the round trip back to SQL and decreases the page load time for the user at the same time reducing the load on the back-end SQL server.

Now thinking about CRM, many users often want to read account and contact information and I thought it'd be cool if CRM could cache the data and serve it from the front-end server. Of course as data gets updated, the cache must be refreshed and the process will get busier on a transactional system. But still, with the right pattern, the performance improvements will be much larger.

Incidentally I ran into Shan McArthur of ADXStudio yesterday and he was telling me about the CRM Developer toolkit that they're building. He says this toolkit addresses this very problem in that it'll cache the data using .NET caching and does Cache Invalidation when the data gets updated. There is a lot more in the toolkit and I can't wait to check it out.

At the end, I must say I'd love to attend every one of those interactive discussions if only we had enough room for all the people. But as I mentioned earlier, maybe it is good that they limit the number of attendees.

Skip to main content