jGrowl Notifications for SharePoint 2010 – Part 3

This article is the third one of “jGrowl Notifications for SharePoint 2010” series. If you haven’t read previous articles, you can find them here:

jGrowl Notifications for SharePoint 2010 – Part1

jGrowl Notifications for SharePoint 2010 – Part2

Also, now SPNotifications is published on CodePlex. Articles above basically explain the details of the initial release.

In this article, I’ll try to show some additional features of jGrowl functionality such as pooling of notifications, different positioning of notification boxes on the screen …etc. In addition to that, you can also find my Load Testing findings for SPNotifications. Results are way better than I expected!

Pooling of Notifications

There is a jGrowl.defaults.pool property which allows you to limit number of notifications shown on the page. Once a notification is closed, next one will be displayed after that. This is a great functionality which prevents notification boxes from crowding your page.

Here it is in action.. Let’s say you have 1000 notifications – titled from 1 to 1000 🙂 Assume that you’ve already read the ones from 3 to 9. In this case having pooling parameter set to 3, you’ll see the following on your page.

Now I close notification #10 above after reading it. You’ll see that notification #11 will appear as soon as you close notification #10 – as seen below.

Load Testing

So far, I’ve tested SPNotifications with 1K and 10K notification items respectively. I used a simple powershell script to bulk-insert items into the list. You can find this script in this post, where I was trying to insert 1 million items to test List Throttling.

I must say as number of items increased, I had to change SPServices call from async false to true. However, this also came with its side-effect which I’ll try to mention shortly.

Firstly there is almost no effect of 1K items while displaying notifications. Notifications are displayed as soon as the page is loaded. On the other hand, from end-users perspective, it doesn’t really matter if notifications are shown right after page loads or maybe 10 seconds later. An end-user is not really waiting for notifications right away after page load. They will show up whenever CAML query execution is complete.

Based on my load tests, which I performed for 3 sets of loads – namely 1K, 5K, and 10K – I can say that notifications were displayed after:

(after page load completes)

1K – less than 1 sec

5K – 2-3 seconds

10K – 8-10 seconds

Also note that default threshold for a list is 5000 items. This makes “2-3 seconds delay” still acceptable..

So, What to do if number of notifications exceed 5K??? Probably i can answer this question with another question: “Do we really need to keep all those ‘Read’ notifications?“. Probably not! One way to keep number of notifications low would be to delete notifications as soon as they are read.

What if some of those notifications are very important and needs to be tracked down later on for some auditing or reporting purpose? In this case, it’d be wise to maybe to add a ‘Importance‘ column to the list. Delete the ‘medium and low importance’ notifications and keep ‘high’ ones.

Basically, this is the area I’ve been thinking to improve and scale out so that all those above and similar questions can be answered. At this point, i’ll stick to one list. We’ll see how SPNotifications will evolve in time.

zieglers