SharePoint Search Topology Limits Clarified for the Crawl Component

As more environments begin scaling out to the documented limits for Search, a common question tends to get asked... "Does the Crawl Component count against the 64 component limit?" The short answer is... no, the Crawl Component does not count against the 64 component limit, and the documentation stating this has now been updated here (see the limits described for "Crawl Components" and "Search Components"):

Software boundaries and limits for SharePoint 2013
https://technet.microsoft.com/en-us/library/cc262787.aspx#Search

For the longer answer, it makes sense to go back to see what the "Limits and Boundaries" formerly stated (until recently last week) to describe the limits for the Crawl Component...

Limit	Maximum value	Limit type	Notes
Crawl components	1 per server	Supported	There is no individual limit for the number of crawl components per Search service application. Instead the limit for the total number of search components per Search service application limits the number of crawl components.
Search components	64 per Search Service Application	Supported

Before going forward, let's tangent with a brief bit of background on the 64 component limit. With SharePoint 2013, the legacy SharePoint 2010 Search and FAST Search code bases were merged under a single umbrella. However, if you pull back the covers far enough, we can still see two systems at play where each resembles its predecessor and each with its own Admin Component.

The Crawl Component and the parent SSA object are largely managed by the Legacy Admin component that existed in SP2010. This is also referred to as the "Crawl Admin" because much of the object model calls for managing content sources and starting/stopping crawls gets handled by this Legacy Admin component. You can see the Legacy Admin component with $SSA.AdminComponent, but the object to which this refers is different than the Admin Component presented in the Topology web part you see in the Central Admin > Search Administration page.

The parts of Search that evolved from FAST are internally known as the Juno system (e.g. all the components in the Topology other than the Crawl Component). The Admin Component seen in the Central Admin > Search Administration page (or listed in the output of $SSA.ActiveTopology.GetComponents()) primarily manages the state of the Search Index as well as all of the Juno components (again, everything but the Crawl Component).

The 64 component limit is tied to the [Juno] Admin Component's ability to manage/synchronize all the other Juno components in a timely manner. Given that the Crawl Component is not part of the Juno system, it did not make sense to include the Crawl Component when considering this 64 component limit.

Being said, the Limits and Boundaries documentation has been updated accordingly, which now states:

Limit	Maximum value	Limit type	Notes
Crawl components	16 per Search service application; 1 per server	Supported
Search components	64 per Search Service Application	Supported	This limit does not include crawl components. The sum of the other search components must stay within this limit.

In other words, you can now have a topology with, lets say, 68 total components (e.g. $SSA.ActiveTopology.GetComponents().Count) that would be considered supported as long as there were no more than 64 Juno components (e.g. the number of Admin, CPC, Index, QPC, and APC components). So. for this particular example where the topology has 68 components, at least four of them would need to be Crawl Components (e.g. 68 total components - 4 Crawl Components = 64 Juno Components).

I hope this helps...