Demo
RBS Performance Results on SharePoint 2010 SP1
Publicado por reena en NetApp for Microsoft Environments encendido 03/02/2012 02:48:49 PM
Reena Gupta - Reference Architect, Microsoft Business Unit
Many times in the SharePoint 2010 deployments, there is a strugglegoing between the Infrastructure teams and the end users. Users might complain about errors, timeouts, and slow performance while reading or writing their large files. Infrastructure teams may not realize that their SharePoint deployment which is completely using the SQL databases for storing all the documents and files is actually being the bottleneck. There had been guidance on using the Remote BLOBStorage with SharePoint to improve the performance, but the Infrastructure team needs the proof points.
Recently we did the performance testing for RBS (Remote Blob Storage) on SharePoint 2010 SP1. The objective for this testing was to compare SharePoint throughput and the file I/O performance while all the documents are in SQL content databases vs. all BLOBs are stored in the Remote BLOBStorage and only metadata in the SQL content databases. The test results clearly show the value of using RBS with the SharePoint deployments and support Microsoft recommendations on the file size.
Microsoft recommends to use RBS, when the documents stored in SharePoint are >1MB and any documents <256KB are best stored in SQL databases only. To prove the RBS value, I created the test environmentfor SharePoint 2010 with 2 WebApps - one as ‘SQLNative’ to keep all the documents completely in the content DBs and other webapp as ‘SQLRBS’ to keep all the BLOBs for any document >1KB in the Remote BLOB Storage in a SMB share, while the metadata was stored in content DBs. I built the SharePoint corpus of 1TB data for each webapp consisting of different size of files as 100KB, 1MB, 10MB and100MB. Each webapp had 5 site collections with one content DB each.
Test Environment
Servers:
1. 4-5 Web Servers (Web Front End servers) running SharePoint 2010SP1,
2. 1 Visual Studio 2010 Load Test Controller,
3. 6 Visual Studio 2010 Load Agents,
4. 1 SQL server running SQL 2008R2
5. 2 Media Servers running Windows 2008R2 SP1.
Software:
1. NetAppSnapDrive 6.3R1 to manage the database and logs LUNs,
2. NetApp Snap Manager for SQL 5.1 to manage the SQL databases,
3. NetApp Snap Manager for SharePoint 6.0 to manage SharePoint and provide the RBS provider.
Note: SnapManager 6.0 for SharePoint Architecture has been described in my previous blog.
All the servers were virtualized using Hyper-V and distributed evenly on 4 physicalservers with SQL server hosted on a dedicated physical server. The backend storage was NetApp FAS3170 Controller with 600GB SAS disk drives used for hosting SQL content DBs and logs for both ‘SQLNative’ and ‘SQLRBS’ webapps and 1TB SATA disk drives used for hosting the SMB shares for Remote BLOB Storage. The network bandwidth between the servers and the storage controllers was 10GBE for all the datacommunication and the management network bandwidth was 1GBE.
The baseline test cases included a mix of read-write operations with a ratio of 77% reads and 23% writes. Some percentage of the operations was metadata intensive.
Test Mix:
RBS Performance Results
1. RBS Reduces SQL Server CPU Usage: As RBS removes some I/O operations from SQL Server, the overall CPU load that SQL Servergenerates with BLOBs going directly to RBS is significantly less than the same workload running against a native SQL Server BLOB store.
2. RBS Relieves SQL Lock Pressure: Since SharePoint writes all documents for a given content database to a single table, we see significant SQL Server Wait time due to locking of the tables in workloads that include concurrent document uploads. Our base case...
Regístrate para leer el documento completo.