Redis Cache

Caching in Microsoft technologies has many forms and options.  You can have server side cache, client side cache or downstream caching such as proxy servers.

Server Cache in .NET:

• in-Memory store: This type of server cache historically was very useful for maintaining state and having users tied to a collection of objects/knowledge and is extremely fast.  You need to think about multiple instances, or how to route traffic.  So you can tie a user to use static routing to ensure user Joe's session always goes to server 3.  But is server 3 dies, you loose all the cache data.  
• Local storage cache works well for larger amounts of data that are too big for memory cache but as they are storage based are much slower.
• Shared/ centralized caching, allows shared cache, a good example is using SQL server for caching and the user can go to any front end web server and the cache is pulled from SQL.  Allows for failure, no need to performed fixed user routing of requests (sticky sessions).  It is slower as cache is pulled from a central service that in turn goes into SQL to retrieve the data.
• Azure Redis cache is a form a of Shared Caching.  The cache is better if used in memory like Redis cache does.  A Redis Cache is a service that is optimized for performance and allows stateless caching to work across server instances.  So while it needs to travel over your network in Azure, it is not as fast as local cache but extremely fast for centralized caching.  Redis is pretty advanced and has clustering and replication to ensure performance is good.

https://docs.microsoft.com/en-us/azure/architecture/best-practices/caching

Client Side Cache:

• Browser can hold information in session but it is not secure or at least less secure than server side cache.
• CDN's are a way of retrieving data from an optimized central store but useful for static files and data.
• Adding headers to HTTP requests allow for downstream caching.  For example, I offer a REST API (e.g. C# Web API) that return a feature product that change hourly.  I could easily set expiry caching to 10 min.  The product is changed every 10 minutes for each user and added to the users local cache.  So if an average user is on for 20 minutes, they only to 2 of their 10 requests to the REST API, the other 8 calls are served locally.  Couple with Server caching, the requests to the server can be fast, with very few calls to the back-end database yet the relatively static data causes far less demand on the web service.
• Validation Caching - is client caching, that stores data locally, but a request is sent to the server to ask if there is a change, if there is a change send back the new data.  If the data has no changed, a 304 response is sent and the browser uses the previously stored local cached data.

Client and Server (Redis) side Caching on Azure

Note:  The diagram only outlines client caching referring to the browser or end device.  Using HTTP headers, you can also set down stream proxy caching.  This is also generally referred to as client caching.

Firefox has a nice short cut to check you client cache is working.  Open Firefox, and request the URL that shall cache a resource on the local client machine.  then in the URL type in "" and check what is being served up locally.

Basic Caching Options:
1. Client Cache (local) - saves on network call and serve side processing.  Can hold client specific static data.
2. Client Cache (proxy) - saves on server side processing.  Can only hold generic static data.
3. Server side Cache (Redis) - saves on computing resources by not having to connect to data sources on every request.  Useful for static share data.

Cross Cutting Concerns for SharePoint 2013

Overview:  Last week I was speaking to a smart chap and he dropped the term Cross Cutting Concern as we were discussing SharePoint Host Apps (SPHA) and JavaScript.

Problem:  When creating apps for SharePoint 2013 multiple solutions need to address cross cutting concerns.  In the past I deployed a SharePoint library with caching, logging, lazy loading and various other "Cross Cutting Concerns", now for Provider Host Apps (PHA), SPHA and JS embedded within pages and Single Page Apps (SPA) we need frameworks for clients to address common components.

Hypothesis:
Caching for Client Side Code: In JavaScript you can either cache using the client cookie which is small or in HTML 5 based browsers use the JavaScript local store. 
Caching on the Server: All the normal Caching of C# or Azure are available.  Also look at Redis.

References:
http://en.wikipedia.org/wiki/Cross-cutting_concern
Update 27/01/2015:
http://channel9.msdn.com/blogs/OfficeDevPnP/SharePoint-Apps-and-client-side-caching

Central Admin is not working correctly - You may be trying to access this site from a secured browser on the server

Problem: Using Central Administration (CA) on SharePoint 2010 you can't use the menu and you see the following information "You may be trying to access this site from a secured browser on the server. Please enable scripts and reload this page."

Initial Hypthesis: FireFix work so it is a I.E. 8 issue.

Resolution: As suggested on the MSDN formun turn of the IE

More Info:
http://social.msdn.microsoft.com/Forums/en/sharepoint2010general/thread/4cf3a740-dddf-4c08-bc36-03efc731eff8
http://social.technet.microsoft.com/Forums/en/winservergen/thread/e87585de-d365-48c8-b08f-1050d68724ed

Dropdownbox population options for custom SharePoint applications

Problem: I need to populate combo boxes and drop down list boxes on a customised SharePoint page using a web part.  The web part has 5 of these lists that are populated choice fields.

Initial Hypothesis: I could use the Enum generated by Linq to SharePoint for the choice field options but to change the available options would require me to re-generate the SPMetal proxy.  I could use lookup lists and then use Linq to SharePoint but this is pretty heavy for simple choice columns.  So I chose to use the SP Server-side Object Model, this is not too heavy as it is only looking up the columns and looping thru the choices however I have 5 drop down lists doing this repeatedly for a lot of users.  So although it is working it could be better if the results were cached for a minute.  This would allow choice options to be change and the using a cache duration of 1 minute, the longest the wait would be is 60 seconds before users see the updated lists.

Resolution: I cached my list item collections, on the page I had 5 choice fields.  By adding the caching I am getting a 36% performance increase in my Page Request response time.  So not as good a return as I was expecting but still a considerable improvement. 

Test Information:
I used a sample of 10 items per request type.  The 10 pages requested each for the cached list item collections and the un-cached version.  I excluded the 1st page request for warm up. 
All the results were pretty consistent.
The testing was done on a local development machine.

Developer Dashboard showing improved response times using cacheing.

Code to cache list item collections:
HttpContext.Current.Cache.Insert(keyname, null, DateTime.Now.AddMinutes(1), Cache.NoSlidingExpiration)