Sizing and Scalability Considerations

Sizing Variables

Variable	Notes
Total number of users	1 CPU core per 75 concurrent users. 2 minimum: 1 for OS, 1 for CSM. 50 MB of memory per session for application and web servers.
Concurrent licenses used	Use a 1:3 ratio for Desktop Client and Browser Client users. Example: 50 to 100 licenses = 150-300 Desktop Client and Browser Client users, 30 percent Desktop Client and Browser Client users concurrent (1:3). 5 percent concurrent coverage for CSM Portal users. Example: 900 Portal users = 18,000-20,000 user pool. Consider factoring 600 MB of storage per license per year.
Number of records created (example. Incidents or Changes)	If the record count is especially high, consider increasing the memory and processors on both servers.
Number and type of CSM reports run	If running multiple reports frequently, or reporting historical/trend data for extended periods of time, consider increasing the memory and processors on both servers.
Number and type of CSM attachments used	If using many large attachments, consider doubling the amount of storage.

Database Installation Considerations

CSM uses Microsoft SQL Server as a back-end database (see the System Requirements for supported versions). Organizations typically host CSM on a centralized database server. This setup is efficient because it simplifies management and ensures that CSM data participates in an existing backup/recovery plan.

Consider the following:

Network activity exists between the CSM server and database server. There is typically a fast connection between the two machines, though firewalls might require configuration to allow this communication.
CSM servers must have appropriate security access to the database. This is accomplished by either providing SQL credentials for the database to the CSM server or ensuring that the account used by the CSM servers has appropriate rights on the database server (and also has appropriate local rights on the CSM server machine).

Server Components Installation Considerations

By default, servers and server components are installed on a single server. However, the components can be separated onto additional servers if necessary.

Consider the following reasons for separating components:

Support of existing infrastructure: Customers commonly have separate servers set up for specific functionality. Typically, this includes either the database or the web server.
Scalability: When the number of concurrent users increases substantially or when the automation load is high, separating secondary services might improve efficiency. Typically, this includes secondary services expected to use a significant amount of data. For guidance, see Scaling CSM.
Server Farms: The Cherwell server and CSM Web Applications support server farms using a Redis cache to handle state management between multiple servers when used with a hardware load balancer. For guidance, see Scaling the CSM Web Applications.

Deployment Considerations

Prior to deployment, consider factors that might affect performance, such as:

Network performance.
Database performance.
Complexity of the SQL database network configuration.
Use of CSM on a shared or dedicated server.
Use of CSM in a high availability environment.

Trusted Agent Considerations

Prior to deployment, consider the impact of Trusted Agents on scalability and system performance. In most cases, the use of Trusted Agents adds only a marginal amount of overhead, but in the case of the Trusted Agents for email, the impact can be as much as a 40 percent reduction in the throughput of emails. For guidance, see Trusted Agent.