Skip to main content

Affects of caching on UI service layer

In a previous post I talked about the how the use of an ORM would have saved development time. Having made the statement I thought I would share how the UI service layer we introduced still received a considerable benefit from the introduction of an in-memory cache.

The constructor for the service is shown below, as you can see pretty standard really, the interesting interface is the ICacheProvider. As I said in the previous post this service interface and implementation would not exist if an ORM had been used.
The ICacheProvider interface is literally an abstraction around the MemoryCache provided by .Net framework, this then allowed a null caching provider to be defined as well as testing isolation.
public interface ICacheProvider
{
    bool Add(CacheItem item, CacheItemPolicy policy);
    object AddOrGetExisting(string key, object value, CacheItemPolicy policy, string regionName);
    bool Add(string key, object value, DateTimeOffset absoluteExpiration, string regionName);
    bool Add(string key, object value, CacheItemPolicy policy, string regionName);
    CacheItem AddOrGetExisting(CacheItem item, CacheItemPolicy policy);
    object AddOrGetExisting(string key, object value, DateTimeOffset absoluteExpiration, string regionName);

    object Get(string key, string regionName);
    CacheItem GetCacheItem(string key, string regionName);
}
Normally the application is configured to use the in-memory cache provider via the DI setting in the boot-strapper (we used NInject for the IoC):
This was changed to the null implementation for the first part of the test:
The test involved loading some average sized data (300 odd widgets) and monitoring how many sql statement are executed against the database. The test was first performed with the null cache provider and then with the in-memory cache provider. I monitored the performance using SQL Server Profiler and the application log file. The profiler was configured with the following filter criteria:

Using the null cache provider produced the following results in SQL Server Profiler, the highlighted area shows there were over 3200 individual SQL statements executed!
Using the in-memory cache provider produced the following results, the highlighted area shows only 1700 individual SQL statements executed, still high but a lot better.
So when caching is enabled for the service we are seeing an decrease of approximately 40% in the number of calls to the database.

This translate to a time saving of approximately 25% according to the log file:

The log file gives the impression the load times for data aren't that bad, but this is on a dev machine which is hosting the database locally, so the times are still high for the amount of data being loaded. What's interesting is the performance on the client network, they are seeing average load times of 20 seconds - WTF!

This is simply because of the remote nature of the database and quality of network infrastructure, the client is happy with the current performance so the code is 'good enough'.




Comments

Popular posts from this blog

WPF tips & tricks: Dispatcher thread performance

Not blogged for an age, and I received an email last week which provoked me back to life. It was a job spec for a WPF contract where they want help sorting out the performance of their app especially around grids and tabular data. I thought I'd shared some tips & tricks I've picked up along the way, these aren't probably going to solve any issues you might be having directly, but they might point you in the right direction when trying to find and resolve performance issues with a WPF app. First off, performance is something you shouldn't try and improve without evidence, and this means having evidence proving you've improved the performance - before & after metrics for example. Without this you're basically pissing into the wind, which can be fun from a developer point of view but bad for a project :) So, what do I mean by ' Dispatcher thread performance '? The 'dispatcher thread' or the 'UI thread' is probably the most

Showing a message box from a ViewModel in MVVM

I was doing a code review with a client last week for a WPF app using MVVM and they asked ' How can I show a message from the ViewModel? '. What follows is how I would (and have) solved the problem in the past. When I hear the words ' show a message... ' I instantly think you mean show a transient modal message box that requires the user input before continuing ' with something else ' - once the user has interacted with the message box it will disappear. The following solution only applies to this scenario. The first solution is the easiest but is very wrong from a separation perspective. It violates the ideas behind the Model-View-Controller pattern because it places View concerns inside the ViewModel - the ViewModel now knows about the type of the View and specifically it knows how to show a message box window: The second approach addresses this concern by introducing the idea of messaging\events between the ViewModel and the View. In the example below

Implementing a busy indicator using a visual overlay in MVVM

This is a technique we use at work to lock the UI whilst some long running process is happening - preventing the user clicking on stuff whilst it's retrieving or rendering data. Now we could have done this by launching a child dialog window but that feels rather out of date and clumsy, we wanted a more modern pattern similar to the way <div> overlays are done on the web. Imagine we have the following simple WPF app and when 'Click' is pressed a busy waiting overlay is shown for the duration entered into the text box. What I'm interested in here is not the actual UI element of the busy indicator but how I go about getting this to show & hide from when using MVVM. The actual UI elements are the standard Busy Indicator coming from the WPF Toolkit : The XAML behind this window is very simple, the important part is the ViewHost. As you can see the ViewHost uses a ContentPresenter element which is bound to the view model, IMainViewModel, it contains 3 child v