Hardware Performance

Applies To: System Center Service Manager 2010

An important part of Service Manager performance depends on a hardware configuration and deployment topology that is planned to handle the needs of your organization. The following sections provide general guidelines to consider when planning for adequate hardware performance.

Hardware Performance

The following are hardware bottlenecks most noticeable in Service Manager with significant load and amount of data in the Service Manager database:

  1. The most common bottleneck will be memory and I/O on the SQL Server. If you have the resources, investing in more memory and a faster IO sub system to improve SQL Server I/O will achieve better performance.

  2. If you expect to have many consoles connecting to a management server, you can improve performance to handle peak load by investing in additional CPUs and memory for the management server, or planning to install a secondary Service Manager management server.

  3. Be aware of recommended minimum hardware for each role, as described in this document.

The Role of Virtual Machines

Many organizations use virtual machines to host Windows Server applications and Service Manager server roles such as the management server, data warehouse server, and the Self-Service Portal are no exceptions. Such use might range from all server roles being virtualized or some other combination of virtual and physical computers. We do not recommend any specific virtual to physical computer ratio because the needs of your organization are inherently unique. However, the minimum hardware requirements for each software role apply to physical computers—if you decide to virtualize a software role you should plan to ensure that you have additional hardware resources for each virtual computer.

Database servers are vulnerable to poor performance on virtual machines if the following planning guidance is not followed.

Service Manager Baseline Test Results

Service Manager has been baseline tested for performance and scalability using various deployment scenarios using the minimum hardware recommended with physical computers. More specifically, the scenarios were tested with databases pre-populated and Service Manager consoles creating and updating incidents and change requests in a loop. The database was pre-populated with information for two tests.

Test 1 consisted of 20,000 computers, 20,000 users and all necessary configuration items, which was about 250,000 configuration items totaling about 2.5 million rows in the database, and the test included 40 active Service Manager consoles.

Test 2 consisted of 50,000 computers, 50,000 users and related configuration items, which was about 700,000 configuration items totaling 6 million rows in the database, and the test included 80 active Service Manager consoles.

In order to meet the response time goals for 50,000 configuration, the SQL Server memory had to be increased from 8GB to 32GB.

  • During testing, 200 incidents and 50 change requests for 20,000 configuration, and 500 Incidents and 125 Change Requests for 50,000 configuration, were generated each hour with 3 to 4 notification subscriptions and templates being processed for each incident and change request.

  • Typically in the baseline, workflows such as notification subscription processing and template application ran within 1 minute of each work item being generated. However, a small number of workflows could take 5 minutes or longer to complete.

If your organization plans to have fewer than 20,000 supported computers and consoles and fewer workflows, then your Service Manager performance should normally be acceptable, even if some of the Service Manager roles are hosted on virtual computers.

However, if you plan to add additional supported computers in the Service Manager database then you should plan to increase the amount of RAM for the Service Manager database server beyond the minimum requirements listed in this document. For example, in the baseline test 8 GB of RAM was installed in the Service Manager database server that contained records for 20,000 computers. Afterward, you should add 8 GB of RAM for each increment of 10,000 of computers that you plan to support. For example, for 50,000 computers plan for 32 GB of RAM. While testing the 50,000 computer configuration with 32 GB of RAM installed on the SQL server, performance was improved to a state where there was no longer any decreased effect, compared to before additional computers were added.

Network latency was also tested in the baseline. Network latency was introduced between the Service Manager console and the Service Manager management server.

Note

The Service Manager database server and Service Manager management servers should be on a low-latency LAN; network latency between the Service Manager database server and the Service Manager management server may lead to significant degradation of Service Manager performance.

  • Where network latency is less than 100 milliseconds, overall Service Manager console response times were found good.

  • Where network latency was 150-200 milliseconds, performance was noted as usable with up to a 40% degradation in response time in some scenarios. With latency between 150-200 milliseconds, you should plan to evaluate the key scenarios for your organization and determine if Remote Desktop Connection is a better option.

    Note

    Expanding service maps in the Service Manager console was slow with any amount of latency.

  • When network latency exceeded 200 milliseconds, overall Service Manager console response times were observed as poor. If your latency exceeds 200 milliseconds, you should plan to use Remote Desktop Connection or another similar remote access solution for operational tasks. However, because occasional administrative tasks are less common you might not need remote access for them.

Did you find this information helpful? Please send your suggestions and comments about System Center Service Manager documentation to scsmdocs@microsoft.com.