This documentation supports the 9.1 version of Remedy IT Service Management Suite.

To view the latest version, select the version from the Product version menu.

Sizing and deployment considerations

This topic contains information and terminology to help you determine hardware sizing and deployment requirements for your organization's usage.

Use cases and value paths

Before sizing can be determined, you must understand the business and organizational requirements and use cases for each solution. Number of users, transaction types and volume, and customizations (for BMC Service Request Management and BMC Atrium Orchestrator) impact sizing. BMC Remedy ITSM value paths and use case information is located in the  Key concepts  in BMC Remedy ITSM Suite 9.1.

Following are some examples of use cases and factors that can impact sizing:

  • Large amounts of CMDB data
  • Software license management
  • Heavy incident volume from event management
  • Knowledge management and Full Text Search (FTS)
  • Large numbers of BMC Service Request Management or BMC Atrium Orchestrator customizations
  • Integrations


The following information is for general purposes and is not specific to any particular value path.

Sizing BMC Remedy ITSM environment

BMC recommends centralized deployment with Web/Mid-tier servers, AR system servers and database server co-located in the same datacenter. There is very little value in hosting web/mid-tier servers closer to the user location.  

You can configure BMC Remedy ITSM in a load-balanced environment to direct user interactions to the load-balanced BMC Remedy AR System mid tier and BMC Remedy AR System servers while assigning dedicated non-user functions and responsibilities to specific instances of BMC Remedy AR System server (see references to back end servers in Sizing baselines. For example, escalations, integrations, reconciliation, and notifications can be separated from "user" servers to ensure that these services do not impact user activity. This is a reliable way to provide consistent high performance services as well as scale the installation safely.

Similar to dedicated BMC AR System servers for non-user related functions, additional dedicated servers at the web tier should be considered if web services are implemented for BMC Atrium CMDB or BMC Remedy ITSM.

In a BMC Remedy AR System server group, the host computers do not all require the same processing power and memory. For example, the back-end servers can use servers with more or less processing power and memory.


When sizing a system, make sure to consider the following:

  • The sizing is based on physical CPU cores rather than logical cores. This is regardless of whether the tier is physical or virtual. 
  • While features like hyper-threading increases the logical threads and can increase the performance, sizing should be based on physical cores. 
  • With hypervisor-based x86/x64 systems like VMware ESX Server, BMC recommends not to over-subscribe especially for production environment. It is okay to over-subscribe in Development and QA environment.
  • BMC Remedy mid-tiers and AR system servers can be virtualized. 
  • Database tier can also be virtualized, especially for small and medium model customers. 

BMC Remedy Mid Tier servers and web infrastructure

Consider the following:

  • BMC recommends centralized deployment over distributed deployment with AR mid-tiers servers co-located with AR system servers.
  • The BMC Remedy AR mid tier servers can scale horizontally as well as vertically. Consider scaling vertically first before scaling horizontally.
  • Use at least two BMC Remedy Mid Tier servers to provide high availability and failover capability.
  • Consider enabling clustering for seamless failover. Make sure to limit the number of mid-tier nodes to 3 or 4 to limit the overhead of session replication in clustering mode.

BMC Remedy AR System server

Consider the following:

  • The BMC Remedy AR system servers can scale horizontally as well as vertically. Consider scaling vertically first before scaling horizontally.
  • BMC recommends adding back-end AR system server to support batch activities like approval, assignment, FTS, email etc. For heavy Atrium CMDB load deploy an additional backend server as processes like normalization and reconciliation engine are CPU intensive. 
  • Make sure to balance the batch workload across back-end AR servers using ranking and failover form. Ensure enough capacity for failover scenario. Avoid failing-over batch workload to user-facing AR servers for non-critical workload. 
  • Make sure to size AR system properly if you are using Smart IT applications. Smart IT relies heavily on FTS, a CPU intensive operation. 
  • Ensure AR system servers are properly configured based on the recommendations provided in the performance tuning guide. 

Estimating the number of concurrent users

The number of concurrent users depends on the total end-user population and on the way the system is used. For example, with the BMC Service Request Management application, if only a few services are deployed, the number of concurrent users is low; if a large number of services are deployed, the system experiences a higher load. The number of concurrent users is best established by looking at the load on the existing system that is being replaced or upgraded.

In the absence of this data, BMC suggests the following guidelines for creating an initial estimate on the number of concurrent users. Note that these are estimates rather than accurate numbers.

Type of user

Number of concurrent users

Service Desk

100 percent of total population

Change Management

10 percent of total population

Self Service

1 – 2 percent of total population


100 percent of total population

BMC Smart Reporting users

10 – 20 percent of total population

For example, if you have an IT staff of 900 employees, all of whom use the Change Management system, you can assume that about 90 of them are concurrent at any time. Similarly, if you have 100,000 employees who are using BMC Service Request Management, the concurrent count can vary from 1,000 (which is 1 percent) to 2,000 (which is 2 percent). This high variance must be evaluated based on your plans to roll out services. If you intend to host many services on BMC Service Request Management, use the high count. If you plan to limit the number of services, use a smaller count.


Database tier can also be virtualized, especially for small and medium model customers. BMC recommends validating virtualized environment by conducting a representative load test. 

BMC does not recommend placing a firewall between the AR System servers and the databases. If firewall is a critical requirement, make sure to configure it in a way to minimize the impact on performance and scalability.   

BMC Smart Reporting 

Key points to consider while deploying Smart Reporting:

  • Reporting server scales horizontally as well as vertically.
  • BMC recommends turning session replication off as there is a significant overhead. The overhead is higher with increased workload or when more nodes are added to the Smart Reporting cluster. Please review benchmark reports for details on the overhead caused by session replication.
  • You can add nodes to support high availability. 

Database sizing

BMC Smart Reporting can use the BMC Remedy AR System database, but this might affect the performance of the database server. BMC recommends that you use a separate reporting instance of the BMC Remedy AR System database to support the reporting requirements.

Benchmark Reports:

Was this page helpful? Yes No Submitting... Thank you


  1. Steven Casey

    What about version 9.x components? The information I see is for older versions. Thanks in advance.

    Feb 03, 2016 12:29
  2. Andy Walker

    In particular - what about Smart Reporting?

    Jun 24, 2016 08:38