Recommendations: Query throughput (FAST Search Server 2010 for SharePoint)
Applies to: FAST Search Server 2010
This article describes our recommendations achieving high query throughput in a Microsoft FAST Search Server 2010 for SharePoint environment. For a complete recommendations overview, refer to Performance and capacity recommendations (FAST Search Server 2010 for SharePoint).
There are two main parameters that you must consider when dimensioning for query performance:
Maximum number of queries
Query latency
You measure the maximum number of queries served in queries per second (QPS). For intranet search solutions this is usually not a limiting factor. But if you must handle peak query rates of more than approximately 5 QPS, you should consider scaling out the search solution for this dimensioning parameter. You can scale out for more QPS by adding more search rows to your deployment. You can also add more query components to the FAST Search Query SSA.
Tip
In SharePoint Server 2010, you can have one parent farm serve queries for multiple child farms. You connect the front-end web servers in the child farm to the FAST Search Query SSA in the parent farm via the SSA Proxy.
The query latency is the average round-trip delay from the point where you issue a query until you get a query result in return. You can reduce this latency by limiting the number of items per column or deploy one or more additional search rows, or both. By adding search rows, you avoid that the indexing load affects the query latency, and you will also achieve increased query availability. We recommend that you deploy a separate search row for deployments where the query latency must be continuously low.
You can also combine a separate search row with a backup indexer. This will provide short recovery time in case of a non-recoverable disk error, with some loss of query performance and incremental update rates. For the highest query performance requirements, we recommend a pure search row.
Note
If you run indexer, item processing and query matching on the same server, you should schedule all crawling outside periods with high query load to avoid decrease in query performance during crawling.
For more information about how to add search rows and scaling out the FAST Query SSA, refer to Recommendations: Redundancy and availability (FAST Search Server 2010 for SharePoint)
The following table summarizes the performance effect of FAST Search Server 2010 for SharePoint search related features. Use these values as a rule-of-thumb but be aware that there are also inter-dependencies between the features that we have not covered in this table.
| Feature | Item processing | Indexing | Query matching | Query processing | RAM - Query matching | Disk access | Disk space | Net/IO |
|---|---|---|---|---|---|---|---|---|
Deep refiners |
M |
L |
L |
H1 |
L-M2 |
|||
Shallow refiners |
L |
H |
H3 |
|||||
Property extraction |
M |
L |
||||||
Trim duplicates |
M |
L-H4 |
||||||
Full-text sorting |
L |
L |
H1 |
|||||
Hit highlighted summary |
M |
|||||||
Complex queries (many terms) |
M |
M |
H |
|||||
Substring search |
L-M5 |
|||||||
Stemming |
L |
L |
L |
L |
||||
Spell check |
L |
L |
L |
|||||
Synonyms |
L |
L |
L |
|||||
High stop-word threshold6 |
H |
H |
H |
|||||
Managed property boost |
L |
L |
L |
H=High, M=Medium and L=Low. When no letter is specified, enabling the feature has insignificant effect on the corresponding resource compared to disabling it.
Notes:
The memory usage pattern is similar for deep refiners and full-text sorting. The query matching component keeps aggregation data for the associated managed properties in main memory. The memory usage effect is proportional with the number of items per column and the number of unique values for the associated managed property.
Deep string refiners with many unique values in the index will have good I/O performance effect on the interface between query matching and query processing nodes. The I/O load performance effect is proportional with number of columns and the QPS in the farm.
We recommend that you use deep refiners for query refinement in most cases, but using shallow string refiners has good I/O performance effect on the interface between query matching and query processing components. The I/O load performance effect is proportional with the average size of the associated managed property, the number of columns and the QPS in the farm.
Duplicate trimming may in certain cases have good I/O performance effect on the interface between query matching and query processing components. The I/O load performance effect is proportional with the average number of duplicates per query result, the number of columns and the QPS in the farm.
If you apply substring search to large managed properties (e.g. the body), this has good effect on the index disk usage.
See Also
Concepts
Recommendations: Content volume capacity (FAST Search Server 2010 for SharePoint)
Recommendations: Redundancy and availability (FAST Search Server 2010 for SharePoint)
Recommendations: Content freshness (FAST Search Server 2010 for SharePoint)
Recommendations: Storage (FAST Search Server 2010 for SharePoint)
Recommendations: Virtualization (FAST Search Server 2010 for SharePoint)