ReaderWriterLock

ReadLock -> Release Lock = 0.00014 ms

WriteLock -> ReleaseLock = 0.00012 ms

ReadLock -> UpgradeToWriteLock -> ReleaseLock = 0.00021 ms

ReaderWriterLockSlim

ReadLock -> ExitReadLock = 0.00005 ms

WriteLock -> ExitWriteLock= 0.00004 ms

ReadLockUpgradeable -> WriteLock -> ExitWriteLock -> ExitReadLock  = 0.00009 ms

So it appears that the ReaderWriterLockSlim is approximately ~3 times faster in most cases.

Note: I came up with these number by writing a c# console App (.net 4.0) which aquired/released locks in a for loop 1,000,000 times with a StopWatch measuring the time taken.

Apparently the way it goes about doing this is by locking the session state object for a user for the lifetime of any handler that requires the session state (anything that implements IRequiresSessionState).  Normally this is a handy feature making it so that developers don’t have to worry about the thread safety issues that would normally come with sharing the same objects between threads.  However in some instances this can lead some some unexpected behavior if you’re not aware of this.

So the other day I was implementing an asynchronous HTTP handler in which I needed to access a user’s session state.  To do this you simply make the handler class inherit from IRequiresSessionState.  However in doing so the users session state becomes locked for the duration of the Async request (in this particular case it could be several minutes before the response was sent).  This caused any subsequent requests which required the session state to hang while they waited for the lock to be released.

So after all of this I can say I learned something interesting and have added a new best practice to my repertoire; don’t use the session state within long running handlers!

http://msdn.microsoft.com/en-us/library/windowsazure/ff795779.aspx

The one thing it forgets to mention is that along with server certificate you also need all of the certificates along the chain of trust back to the root CA which people’s browser trust.  There are multiple ways to do this but the way I found simplest was to import the certificate into a local IIS instance and then use the certificates MMC to export the certificate per this guide:

https://support.comodo.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=1244

Note: Make sure to check the box for ‘Include all certificates in the certificate path’

You’ll also need to reference these certificates in the XML files mentioned in the MSDN article and then you’re all done!

P.S. If you get an error about the certificates’ thumbprint not matching make sure you’re copying the full thumbprint from Azure, the field is longer than what the screen shows, so there is some ‘scrolling’ when highlighting it.

So after some researching I came up with a solution in which I would create a new column of type bigint and then in small batches of 1000 I would update the rows with the converted bigint (I wrote a small C# console app with ADO .NET).  After doing this to every row I deleted the old varchar column and renamed the new column to the old varchar column’s name.

VIOLA!

Since I’ve never particularly liked the feel of C#’s int.TryParse and bool.TryParse methods I decided to create some extension methods for strings which I feel like make the code using them much more readable:
 

/// <summary>
/// Converts a string to an int, if the string cant be parsed then null is returned
/// </summary>
/// <param name="txt">The string to convert</param>
/// <returns></returns>
public static int? ToInt(this string txt)
{
     int x = 0;
     if (int.TryParse(txt, out x))
         return x;
     else
         return null;
 }

/// <summary>
/// Converts a string to a boolean, if the string cannot be parsed then null is returned
/// </summary>
/// <param name="txt"></param>
/// <returns></returns>
public static bool? ToBool(this string txt)
{
     bool x = false
     if (bool.TryParse(txt, out x))
         return x;
     else
         return null;
}

Usage:
 

int imgID = Request.QueryString["Id"].ToInt().Value;
int? height = Request.QueryString["height"].ToInt();
bool? width = Request.QueryString["width"].ToBool();

On a project I’ve just recently started I was tasked to create some SharePoint web services which would serve up data stored in lists.  Having learned recently about a new tool for SharePoint 2010 called Linq to SharePoint I decided I would give it a try rather than taking my normal approach of using CAML inside of SPQuery objects.  Linq to SharePoint is supposed to speed up the development process by creating a DAL for you based on the structure of your SharePoint lists with type safety on all of the lists and the relationships within.  Also making use of Linq to write queries means there would no need for the fairly cumbersome CAML queries which all SharePoint developers have come to know and love.

After a day or so of development with this new tool the one thing that became immediately obvious to me was how limited the actual queries could be.  Perhaps it was because of the data model/relationships of the lists but the majority of the queries I needed to run could not be done with pure Linq since Linq to SharePoint can only run queries which span across no more than two lists which was a huge problem for me since many of my queries needed to span upwards of four lists. (I probably should have noticed that in the documentation).

Query limitations aside I was able to get my code working and decided to do some due diligence and fire up a load tester to see what kind of performance these web services would provide.  What I found was pretty shocking.

After reaching around six requests per second the CPU of the WFE (web front end) would become maxed out with page response times hitting nearly 2 seconds.  This seemed like a surprisingly low amount of performance since the server it was running on had four CPUs and four GB of ram (albeit it is a VM) so I decided to see where all of that CPU time was being spent so I hooked up the Visual Studio profiler and noticed that over 80% of the time was being spent in the inner workings of the Linq to SharePoint code.

At this point I decided to see what would happen if I replaced all of the Linq to SharePoint queries with plain old CAML queries running against the SPList.GetDataTable method.  The load tester was then run and came up with these numbers:

By using CAML queries the WFE was able to handle around 20 requests per second until its CPU maxed out, quite an improvement!

Then per my bosses request I created the same data model with a plain old relational database (SQL 2008r2) to see what the performance for the web service would be like with SQL as opposed to SharePoint.

As most people would suspect this preformed by far the best with the WFE being able to handle around 50 requests per second!

Although this may not have been the most scientific test in the world it definitely shows the overhead which Linq to SharePoint introduces as well as the overhead which SharePoint lists have over plain old SQL.  The lesson I’ve taken away from this is that Linq to SharePoint is okay for smaller/simpler projects where performance is not as important as getting the development done quickly however I will be staying away from it in the future.

I recently ran into an issue on one of my development ASP.Net servers where I would deploy an updated DLL (Dynamic-link library) to the GAC (global assembly cache) but the ASP.Net applications which referenced the DLL would throw compilation errors at run-time saying that newly added fields/methods were not present in the assembly.  I tried uninstalling and re-installing the assembly, adding the new DLL to the bin, and referencing it from there and so on, but nothing seemed to work.

As it turns out, ASP.Net keeps a cached version of the JIT compiled DLL in the C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files directory that was being used instead of the new DLL which was in the GAC.  To fix it, I simply deleted the contents of this folder and everything was right as rain!

-Lee

If you ever have had the need to create your own pagination for SharePoint 2010 lists/views you will undoubtedly have run into a class called SPListItemCollectionPosition which is supposed to handle going forwards and backwards in the paging.  Unfortunately as of this post the documentation on this little gem is non-existent.  So after doing some googling and experimentation here are some things I have learned which can hopefully save some of you some time trying to figure this stuff out.

• All of the data this class encapsulates is really stored in a string with various parameters encoded like a query string
• The parameters which you need to concerned with are:
  • Paged=True This parameter tells SharePoint that you’re trying to paginate the data
  • p_ID Is used in two different ways
    • When paging forward this should equal the ID of the last item on the current page
    • When paging backward this should equal the ID of the first item on the page
  • PagedPrev should be se to TRUE when paging backwards
    • Can be omitted when paging forwards
  • p_[ColumnName] When using sorting this functions in the same way the p_ID field works except the value should come from the column being sorted on, not the ID of the item.
    • [ColumnName] is replaced with the name of the column being sorted on
    • EX) If your sorting on the Title column the parameter should be called p_Title
      • If paging forward it should be set equal to the Title value of the last item on the page
      • If paging backward it should be set equal to the Title of the first item on the page
  • PageLastRow is used when paging backwards.  It should be set to the index of the last item on the current page
  • PageFirstRow is used when paging forwards.  It should be set to the ID the first item on the current page

If you’re looking for more information on how this works one good place to look is in the query string for the out of the box list views.  As you sort and page through the data you’ll see these parameters in the query string of the page which provides a nice place to do some experimentation.  Also please note a few gotchas which I encountered while working with this:

• If sorting is being done on a DateTime column then the value for the p_[ColumnName] attribute needs to be in UTC not local time
• The API only allows for going from the current page to the next or previous page.  You can’t jump arbitrarily between pages
• If filtering is being done on the view then there is no real ‘good’ way to determine if you are at the beginning or end of the pagination.  This is something you’ll have to figure out how to handle on your own

For more information take a look at the following links which helped me out a lot:

• http://charliedigital.com/2010/02/05/paging-with-splistitemcollectionposition/
• http://blogs.msdn.com/b/colbyafrica/archive/2009/02/19/learning-sharepoint-part-vi-list-pagination.aspx

For the past couple of days I’ve been tasked with testing out and learning about SharePoint’s FBA (Forms Based Authentication).  Traditionally SharePoint makes use of Windows Authentication for authenticating users which uses mechanisms built into browers and IIS but limits the UI/UX for logging in to whatever the browser prompts when it receives a 401 from the server.  If you have the need to display an actual login page with username and password text boxes you have to use FBA.

FBA within SharePoint is done using ASP.Net membership and role providers which can pull information from just about anywhere including a SQL databases and AD with the built in providers.  (Note that you can create your own providers http://msdn.microsoft.com/en-us/library/f1kyba5e(v=VS.85).aspx).  Setting these up is a fairly straightforward process involving some Central Administration settings as well as modifying a few web.config files which is described in detail in the following links:

• http://blogs.technet.com/b/mahesm/archive/2010/04/07/configure-forms-based-authentication-fba-with-sharepoint-2010.aspx
• http://blogs.msdn.com/b/alimaz/archive/2009/10/30/configuring-fba-in-sharepoint-server-2010-beta-2.aspx
• http://www.sharepointchick.com/archive/2010/05/06/configuring-claims-and-forms-based-authentication-for-use-with-an.aspx

After setting up FBA for SharePoint you will probobly come across a few caveats in which SharePoint does not act as expected:

• The People Picker does not do partial searches anymore.
  • Using an LDAP memberhsip provider searching for users required knowing the beginning of their username.
    • Can’t search by display name
    • Searching for ‘doe’ would not yield ‘jdoe’ as a result, however searching for ‘jdo’ would
  • Using the SQL membership provider only exact matches to the username would work, defeating the purpose of the search
• The name of the users in the system (Created by fields etc…) only shows their username, not their display name

The problem seems to be that SharePoint handles authentication and user profiles in two different systems.  (IIS/ASP.Net  is used for authentication, whereas profiles and handled by SharePoint specific systems)  So getting the authentication to work is fairly simple but getting the other parts to work is a bit more complicated.  Knowing this now I’ll probably recommend sticking with Windows Authentication unless there is need to authenticate against something other than AD!

Recently I noticed that my SharePoint (2007) development VM was running low on hard drive space.  The VM has a 60+ GB C drive so I was little shocked to see that I only had a few hundred MB left.  After poking around in the file system looking for whatever was taking up all of that space and coming up empty I installed a handy utility called WinDirStat which tells you where all of the space is being used.

Lo and behold the culprits where SharePoint’s log files which over time had grown to over 30 GB!  Since it was my development VM  I simply deleted the logs and freed up half the drive.  Problem solved!