Sunday, May 30, 2010

Linq to SharePoint for Anonymous users performance Part 2

Recently I posted about the bad performance of LINQ to SharePoint when using my anonymous users hack. Well I did some more testing and it turns out that my first test was much too premature. It seems that the statistics I was seeing were due to something entirely different, I am guessing the internal implementation of Linq to SharePoint vs CAML queries, but that is pure speculation.

First I will introduce 2 acronyms because I am a lazy typist:

L2SP - Linq to SharePoint
AL2SP - Anonymous Linq to SharePoint (Uses the workaround I suggested previously)

My recent testing was a bit more structured and thought out, and it showed that there is actually virtually no difference in using L2SP and my AL2SP work-around.

I set up two tests, one was reading all the items from a small list of 20 items 100 times consecutively, an attempt at simulating many web requests of a small list. The second test involved a large list of 5000 items, where each item was named with a random string. The query here was to pull out the top 100 items when ordered by name, thus simulating a random read of items from a large list.

In each test, the Title property of the first list item would be accessed in order to ensure that the retrieved items would be used by the test code and the query would have to run. I noticed that running a CAML query was much too fast before I added this, I suspect there is some clever optimization that skips the query if the results don't get used.

I ran these tests for a signed in user, in which case the code uses L2SP and old school CAML query. I then repeated the tests for an anonymous user which then uses AL2SP and old school CAML query.

Here are the results: The user using IE is logged in and the Chrome user is anonymous.

It is interesting to note that the CAML query does a better job in the 100 times operation, I suspect that there is some cost to setting up the Linq data context and translating the Linq query. However Linq does a much better job in the large list test.

Most important however is that the test results are pretty much the same for AL2SP and L2SP. This means that performance is NOT a problem when using AL2SP. I am curious if any other issues come up with this technique but it looks like it is back in my bag of tricks!

If you want to run the tests I created yourself, I have put the source code here. If you deploy the solution, you get the two lists created and you just need to place the test web part somewhere in the same site. Note that the code was meant just for this test, so it can easily fail if used otherwise. Also note that the feature activation takes a while since it created a list with 5000 items.


2 comments:

Martin Hatch said...

Joe,

Sounds like good stuff, and certainly puts to bed some of the initial fears.

It would be interesting to see some performance counters on the server. I wonder if memory usage is significantly higher (due to loading multiple duplicate SPSite / SPWeb objects into memory?)

I also wonder if the performance would degrade faster under higher load (i.e. a Stress test would potentially break sooner?)

Joe said...

@Martin: These are good points, I'll try to have a look. I'm not sure what load testing against my Mac Mini SharePoint server will show but it may be interesting.