Feature Performance Considerations

Updated: May 13, 2016

Applies To: System Center 2012 SP1 - Orchestrator, System Center 2012 - Orchestrator, System Center 2012 R2 Orchestrator

This section describes the Orchestrator processes that influence performance in a production environment. The focus of this procedure is lies in identifying processes that occur during runtime, in the web service, and during authoring. While many authoring activities occur outside a production environment, considerations for setting up a production environment to test performance should also include variances, for example, whether special requests by an Orchestrator administrator are supported.

Despite the variance in their design and complexity, runbooks have a simple structure. They perform three operations: they run activities, manage published data, and perform branch logic. The following sections provide more details about these operations.

Activity internals

Runbook activities contain two types of code: platform code and domain code. Platform code is built on a framework that is shared between all runbooks. Platform code manages Orchestrator processes. Domain code refers to the code in a runbook activity that manages processes outside Orchestrator. For example, the Invoke Web Service activity contains platform code to handle processing in Orchestrator, such as publishing data, and domain code specific to invoking a web service.

There is little processing variability between runbooks when you compare activities that run similar platform code. Domain code depends on latency issues external to Orchestrator. Potentially, domain code varies greatly between activities. To understand the domain code dependencies and their impact on runbook performance, you must test the performance of individual activities before you determine the requirements for the production environment.

Published Data

Runbooks in Orchestrator share data between activities. Every activity consumes Published Data that earlier runbook activities created. How an activity uses the published data depends on the domain code. All runbook activities publish a minimum set of run-time parameters called Common Published Data. Domain code can, but is not required to, publish data. The Published Data that the domain code creates is called Activity-Specific Published Data. The data that an activity produces can contain data elements that are single or multi-valued. For example, every activity produces a single record of single-value Common Published Data. Domain code can produce multiple records of single and multi-value data.

Publishing data to the orchestration database is a resource-intensive activity. Runbook performance depends on the amount of data that each activity publishes and the performance and resiliency of the computer that hosts the orchestration database. As part of planning your performance requirements, consider the amount of published data your runbooks require and the performance of the computer that hosts your orchestration database.

Branching

Runbook activities create a branch if an activity requires data to pass at the same time to two or more activities. When a runbook starts, processing consists of a single thread. When this thread encounters a branch, a thread is created for each branch. Each thread references the published data from all previous activities along the thread. The total number of threads in a runbook depends on the number of branches used in a runbook. Multi-threaded runbooks require more processing power than single threaded runbooks.

As part of assessing your runbook performance requirements, consider the number of branches you plan to include in a runbook. Runbooks with lots of branches require more processing power on the runbook servers than runbooks that contain no branches.

The operator experience occurs on the Orchestration console and the Orchestrator web service. The Orchestration console is a Microsoft Silverlight-based web application that requires Orchestrator web service to connect to the orchestration database. The Orchestration console and the Orchestrator web service depend on the performance of the orchestration database and the Internet Information Services (IIS) server that hosts the Orchestrator web service.

The Orchestrator web service supports the Service Manager connector. Service Manager targets IT customers who serve approximately 50,000 users. Service Manager request-management scenarios assume that each user submits one request per month. This produces a request volume of 2,500 requests per day (200 requests/hour or approximately three requests every minutes). Service Manager uses the Orchestrator web service to update the status of activities, requiring support for a like number of status requests. Also, note that the Service Manager connector discovers published runbooks. The response time to discover any given runbook folder depends on the number of runbooks in the folder.

Scale Planning