So I’m running a proof-of-concept test farm of SharePoint 2013 on a little VM to test out some of the features. Because I have limited resources on the server I tend to throttle down a lot of the services to the minimum amount in order to run. A big part of that with SP2007/2010 was reducing the search performance. You would think that same would apply in SP2013. However, recently when I was monitoring the server I noticed that search indexing was humming along (Everyone remember the search indexer and what a resource hog it can be?). A quick peak under the hood, and we can see that we still have the ability to throttle search based on the parameter here:
http://technet.microsoft.com/en-us/library/ff608126%28v=office.15%29.aspx
PerformanceLevel | Optional | System.String | Specifies the relative number of threads for the indexer performance: Reduced: Total number of threads = number of processors, Max Threads/host = number of processors Partly Reduced: Total number of threads = 4 times the number of processors , Max Threads/host = 16 time the number of processors Maximum: Total number of threads = number of processors The type must be one of the following values: Reduced, PartlyReduced, or Maximum. |
Doing a little more digging, looks like it doesn’t really do anything except with the crawler component, and even then the effect is pretty minimal in my single server farm. Reminds me of the story of the switch in the server room from years ago. Every week at end of business the switch was moved to the off position and left off for the weekend. First person to come in Monday morning flipped it to on. This apparently happened for years. it wasn’t until we were moving the data center that somebody tried to figure out what the switch did. So, opened the panel to track down the wires in order to move the switch… turns out it wasn’t even connected. I think that is what Microsoft just did to the Search -PerformanceLevel switch.