Performance and capacity testing (FAST Search Server 2010 for SharePoint)
Applies to: FAST Search Server 2010
When testing the performance and capacity of a Microsoft FAST Search Server 2010 for SharePoint deployment, consider the following:
Understand how to measure for your testing goal
If you are measuring for search performance then you will want to measure crawl time, document indexing rates and query matching rates.
Identify your test content
Determine the test content sources that you want to crawl, and verify that you have the required user account and network access to crawl them.
If you create specific test content, you must ensure that you use unique content. A common mistake is to upload the same document, maybe hundreds or even thousands of times, to different document libraries with different names. That can affect search performance because the query processor will spend time doing duplicate detection that it would not otherwise have to in a production environment that uses real content.
Identify a suitable set of sample search keywords and phrases
For more information about how to test performance and capacity of Microsoft SharePoint Server 2010 in general, refer to Performance testing for SharePoint Server 2010.
FAST Search Server 2010 for SharePoint uses the storage subsystem extensively. You can test the raw I/O performance to get an early verification of having sufficient performance. Refer to the following section for more information.
Analyzing raw I/O performance
You can analyze raw I/O performance using a tool named SQLIO (https://www.microsoft.com/downloads/details.aspx?familyid=9a8b005b-84e4-4f24-8d65-cb53442d9e19).
After you have installed SQLIO, the first step is to obtain or generate a suitable test file. The following tests include write operations. Therefore, the content of this file will be partly overwritten. The size of the file should be much larger than the available system memory (by a factor of 10) to avoid most caching effects. The test file can also be generated by SQLIO itself, although not directly for very large file sizes. We recommend that you generate a 1 GB file by using the command "sqlio.exe -t32 -s1 -b256 1g" which will create a file that is named "1g" in the current directory. You can then concatenate this file to a sufficiently large file like 256GB, by the command "copy 1g+1g+1g+…..+1g testfile". To ensure that caching during the test file preparation do not skew the results, you should restart the server before continuing with the tests.
The following set of commands is representative for the most performance critical disk operations in FAST Search Server 2010 for SharePoint:
| Test number | Scope | Command |
|---|---|---|
1 |
1kB read [IOPS] |
|
2 |
32kB read [IOPS] |
|
3 |
32kB write [IOPS] |
|
4 |
100MB read [MB/s] |
|
5 |
100MB write [MB/s] |
|
All the commands assume that a file "testfile" exists in the current directory, which you should locate on the disk that will host FAST Search Server 2010 for SharePoint. Each test runs for 300 seconds. The first test measures the maximum number of I/O operations per second for small read transfers. The second and third tests measure the performance for medium sized random accesses. The two last tests measures read and write throughput for large transfers. The following table shows some example results, with minimum recommendations during ordinary operation in its topmost row.
| Disk layout | Test number 1 | Test number 2 | Test number 3 | Test number 4 | Test number 5 |
|---|---|---|---|---|---|
Recommended minimum |
2000 |
1800 |
900 |
500 |
250 |
16x SAS 10k RPM 2.5" drives RAID50 in two parity groups |
2952 |
2342 |
959 |
568 |
277 |
22x SAS 10k RPM 2.5" drives RAID50 in two parity groups |
4326 |
3587 |
1638 |
1359 |
266 |
22x SAS 10k RPM 2.5" drives RAID50 in two parity groups with drive failure |
3144 |
2588 |
1155 |
770 |
257 |
12x SAS 7200 RPM 3.5" drives RAID50 in two parity groups |
1844 |
1315 |
518 |
677 |
780 |
12x SAS 7200 RPM 3.5" drives RAID50 in two parity groups with drive failure |
1424 |
982 |
531 |
220 |
477 |
12x SAS 7200 RPM 3.5" drives RAID10 |
1682 |
1134 |
1169 |
762 |
692 |
12x SAS 7200 RPM 3.5" drives RAID10 with drive failure |
1431 |
925 |
1154 |
213 |
220 |
12x SAS 15k RPM 3.5” drives RAID50 in two parity groups |
4533 |
3665 |
848 |
501 |
235 |
2x ZeusIOPS 400GB MLC 2.5” drives RAID0 |
52709 |
14253 |
27171 |
360 |
122 |
1x ioDrive 640GB MLC |
83545 |
21875 |
17687 |
676 |
533 |
1x ioDrive Duo 1280GB MLC |
160663 |
42647 |
32574 |
1309 |
664 |
3x ioDrive Duo 1280GB MLC RAID0 |
162317 |
83661 |
44420 |
2382 |
1412 |
3x ioDrive Duo 1280GB MLC RAID0 Non-default option: 4kB block size |
1815932 |
86396 |
47423 |
2340 |
1631 |
3x ioDrive Duo 1280GB MLC RAID5 |
188284 |
87270 |
11800 |
2459 |
545 |
3x ioDrive Duo 1280GB MLC RAID5 with card failure |
126469 |
48564 |
10961 |
716 |
202 |
1This is the average IOPS over the standard 300 second test period. It although starts out as ~3500 IOPS, degrading to a sustained ~1700 IOPS after 3-4 minutes.
2Tested with 4kB block reads due to the different block size formatting.
Note
These results are to a large degree dependent on the disk controller and spindles used. In addition, the numbers in the table reflect a deployment where the disk subsystem is at least 50% utilized in capacity before you add the test file. Note that if you test on empty disks you can get elevated results as the test file is then put in the most optimal tracks across all spindles (short-stroking). This can give 2-3x increased performance. Finally, notice that the numbers in rows highlighted with bold are measured with a forced drive failure.
RAID50 provides better performance during ordinary operation than RAID10 for most tests apart from small writes. RAID10 has less decrease in performance if a drive should fail. We recommend that you use RAID50 for most deployments, as 32kB writes is the least important of the five tests. RAID50 provides near two times the storage capacity compared to RAID10 on the same number of disks. If you deploy a backup indexer, 32kB writes are more frequent. This is because a large amount of pre-index storage files (FiXML) are passed from the primary to the backup indexer component. This may in certain cases lead to a performance improvement by using RAID10.
See Also
Concepts
Performance and capacity management (FAST Search Server 2010 for SharePoint)
Performance and capacity planning (FAST Search Server 2010 for SharePoint)
Performance and capacity monitoring (FAST Search Server 2010 for SharePoint)
Performance and capacity tuning (FAST Search Server 2010 for SharePoint)