SharePoint 2010 Search has many new features but one of which will be most evident to users will be the inclusion of a new WebPart called the Refinement Panel. This WebPart allows the user to refine the search results returned from a query even further by viewing a list of refiners (categories). The user may choose to reissue the query with the refinement to filter the results further. For example, lets say your query returned 100 documents which were authored by 5 different people within your organization. The out of the box (OOTB) the Refinement Panel has an Author refiner and it would show you the 5 Author’s names, which in itself is very interesting, but in addition you could select an author and get a list of just those documents authored by that particular author.
Since MOSS 2007 publishing sites have had a special type of cache known as the object cache. This cache is used to speed up navigation, cross-list queries, and other publishing operations by not constantly having to hit the DB for each request. The cache is scoped at the site collection and Site Collection Administrators have the ability to change several settings related the cache’s operation. One in particular is the max amount of memory which SharePoint will allow the cache to grow. Playing with this setting you may be surprised to learn SharePoint allows this value to range from 1 MB up to 10 TB! Yep, SharePoint allows Site Collection Administrators with a publishing site to set their object cache up to 10 TB for each Site Collection for which they are an administrator.
I have been working with SharePoint for a few years now and have run into many nasty high memory or Out of Memory (OOM) issues. To date many of SharePoint’s memory problems have been discussed as problems with developers not using the Dispose pattern properly when using the SharePoint OM. And while I have found this to be the case I always had a feeling that there was something more, another larger leak which could not be explained simply by not calling Dispose. Sure not calling dispose will keep the SPRequest COM object (which is fairly large) around longer than necessary however ref-counting will clean these up eventually but even with using the correct coding patterns and practices the w3wp processes still seem larger than necessary; even on my development machine when I run stress against an out of the box installation. So there must be something else going on here; and so started my search for Big Foot.