SP SIN Questions – Tips on Controlling Performance of SP SIN

As I mentioned in a previous post on why SP SIN is web scoped, Chris Quick asked me a couple of questions over at SPYAM regarding SP SIN and I wanted to elaborate more on the answers.

Chris’ second question is:

2. I don’t see any data caching in the solution. How will this perform on heavily used sites, could this lead to performance issues?

Again, a great question that allows me to show off exactly how flexible and extensible SP SIN is.

First, any code you add to a site will increase performance load on the server. Anything you add from a single line of code manually to a master page to installing a framework like SP SIN will affect performance to some degree.

SP SIN allows you to tailor your performance loads so that you can change the way SP SIN works depending on where you have the resources to spare. In this article, I’ll discuss a few aspects of this from a client-side and server-side perspective.

Client-Side Performance

SP SIN was designed to allow you to tailor exactly what you do and where you do it. To illustrate this, the two out-of-the-box resource types (scripts and style sheets) include a URL filtering mechanism that allows you to load resources only where you actually need them.

This means that you can increase page load time for clients by sending resources like jQuery, style sheets that affect only certain pages, and so on just where those resources are needed. Your bandwidth will thank you, as will your client download speeds.

If URL filtering is not enough for you, however, you can build or download additional resource types that allow you to target and filter even further or maybe in a completely new way. In the 1.0 release (still available on CodePlex) you can see an example of a custom resource type that allows you to send a resource only to site owners, for example. There’s also a YouTube video that shows you how to build custom resource types in SP SIN.

Regardless of what you do in the filtering department, all SP SIN does from a client perspective is tell the client what to download or to behave. This is exactly the same output that you would add manually if you were editing pages or master pages. Anything you normally do to enhance client-side performance, like using minified scripts or dynamic loading frameworks, works exactly like they do without SP SIN.

So, SP SIN does not cost anything for client-side performance, but allows to to increase client-side performance by only loading resources where you need them.

Server-Side Performance

SP SIN runs on the server, so in general, the largest performance impact will happen there. I’m guessing that’s what Chris meant when he asked about performance issues.

The server performance will mostly be impacted by the number of resources you have in your resource list. By default, all resources need to be evaluated to figure out whether they should run, regardless of whether they actually output anything. So, even if you’re on a page that only need to load a single CSS file, but you have 15 resources in your resource list, each of those 15 resources need to check whether they should load for the current request.

The second factor in determining what the performance impact will be is the resource types you use. The resource types run dynamically loaded server code, so if that code is slow or uses lots of resources, then that will adversely affect performance. If you are a resource type developer, I strongly urge you to keep this in mind when you are building your resource types.

Keep in mind that because SP SIN dynamically loads code at run-time, this means that the first time you load a resource type (like after an application pool reset) you will see a performance impact for that request. However, the code remains in memory after loading the first time, so the overhead of the dynamic loading feature goes away for subsequent requests.

So, SP SIN server-side performance depends on how many resources you have and also the performance on the resource type code.

Note: This is another reason why the scope of SP SIN is site rather than site collection; a more narrow focus means less resources need to load for each request.

Regardless of how many resources are in the list or what code runs in resource types, there are still options for controlling performance, however, and this is where the SIN Cycles may be an option.

SIN Cycles?

SIN Cycles were introduced in SP SIN version 1.2, and is a way for developers to interact with the request cycle of SP SIN (called the SIN Cycle). In short, developers can inject code into any stage of the SIN Cycle, and this opens up a lot of opportunities, for example for building performance enhancing solutions.

One way to do this would be to build a simple caching solution. Again, SP SIN uses normal .NET code, which means that there are plenty of software patterns you can use to cache content.

I’m no caching expert, but I built a simple caching engine that would cache output from SP SIN for 10 seconds. The way I did this was by checking in the AfterContextLoad SIN Cycle event whether a cached version existed, and if it did, I would return a false value from BeforeResourceItemShouldLoadEvaluation to prevent the evaluation and execution of individual resource types.

Note: I actually discovered that I had forgotten to implement the handling of BeforeResourceItemShouldLoadEvaluation so I updated SP SIN to version 1.2.1 to fix this. If you’re using 1.2, you can upgrade if you want to use features that depend on this in SIN Cycles, or you can wait for version 1.3 and upgrade then.

I then added around 40 resource items to the list, and fired off a couple of requests to test the impact (I used the code from the SINCycle sample code distributed with SP SIN 1.2 to check performance). Here are the results:

No cache, first hit:

<!–
SP SIN stats:
Start: 3:01:01 AM
End: 3:01:02 AM
Duration: 0.7488048 seconds
Loaded from cache: False
–>

No cache, subsequent hit:

<!–
SP SIN stats:
Start: 3:10:23 AM
End: 3:10:23 AM
Duration: 0.2496096 seconds
Loaded from cache: False
–>

With cache:

<!–
SP SIN stats:
Start: 3:10:41 AM
End: 3:10:41 AM
Duration: 0.1092007 seconds
Loaded from cache: True
–>

As you can see, there’s definitely a benefit to doing caching, even with my limited skills in this area and a 30 minute solution. I’m certain that some brilliant mind who knows more about caching than I do can come up with an even better way of doing caching.

Who knows, you may even want to build a product for this and sell to users 🙂

.b

Found this article valuable? Want to show your appreciation? Here are some options:

a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.

b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.

c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!

Pin It

Published by

Bjørn Furuknap

I previously did SharePoint. These days, I try new things to see where I can find the passion. If you have great ideas, cool projects, or is in general an awesome person, get in touch and we might find out together.

Leave a Reply

Your email address will not be published.