Share via


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]

sqlio.exe -kR -t4 -o25 -b1 -frandom -s300 testfile

2

32kB read [IOPS]

sqlio.exe -kR -t4 -o25 -b32 -frandom -s300 testfile

3

32kB write [IOPS]

sqlio.exe -kW -t4 -o25 -b32 -frandom -s300 testfile

4

100MB read [MB/s]

sqlio.exe -kR -t1 -o1 -b100000 -frandom -s300 testfile

5

100MB write [MB/s]

sqlio.exe -kW -t1 -o1 -b100000 -frandom -s300 testfile

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)