This documentation supports the 19.08 version of Remedy with Smart IT.

To view an earlier version, select the version from the Product version menu.

Smart IT test methodology

This topic provides the following information:

Test case

For Smart IT Key Actions, End User response time with 100ms latency was also captured during 2000 concurrent user test simulation.

The following table lists key actions for which end-user response time was captured:

ApplicationActions
Remedy with Smart IT
  • Log in 
  • Open console
  • View incident
  • Add incident note
  • Update incident to status Resolved
  • View service request
  • View customer profile
  • Search problem summary suggestions
  • Create service request
  • Search asset
  • View asset details
  • Search knowledge article
  • View change
  • Update change status to Pending
  • Create change task
  • Search by work order filtering
  • View work order details
  • Add work order note
  • Update work order to status Completed
  • Search customer through Smart Recorder
  • Create incident
  • Search by change filtering
  • Approve change
  • Open asset console
  • On Dashboard page select All filters except 1
BMC Digital Workplace
  • Log in
  • Create a post
  • Global Search
  • Create incident

Workload

For test cases that required a workload simulation, a mixed workload was added to the system to simulate a common workload scenario for Smart IT customers. The mix consisted of workloads from the following products and features:

  • Smart IT
  • BMC Digital Workplace
  • BMC Remedy ITSM
  • BMC Email Engine (from Smart IT, BMC Digital Workplace, and BMC Remedy ITSM workloads)
  • BMC Atrium CMDB batch jobs, Normalization Engine, and Reconciliation Engine

The nominal workload environment was defined by the distribution of concurrent users and transaction rates among the test scenarios. This workload was used as the baseline for consistent benchmarking of the performance and scalability of the BMC Remedy solutions over time.

The workload from BMC Atrium CMDB batch jobs was executed during a 1-hour simulation. The BMC Atrium CMDB batch jobs created configuration items (CIs) that were normalized, reconciled, and merged into a BMC.Asset dataset.

Nominal BMC Remedy Application workload distribution

The workload was split for Smart IT, BMC Digital Workplace, and BMC Remedy ITSM applications. Roughly 95% of the user workload was for Smart IT and BMC Digital Workplace; the remaining 5% was for BMC Remedy ITSM. Roughly 80% of the transaction workload was for Smart IT and BMC Digital Workplace, and the remaining 20% was for BMC Remedy ITSM. 

The following table describes the general transaction and user percentage breakdown by application type.

ApplicationTransaction percentageUser percentage
Smart IT universal client39%52%
Smart IT mobile client24%23%
BMC Digital Workplace universal client20%23%
BMC Remedy ITSM17%2%

 

The workload was further split to distinguish from a universal client (a computer browser) and a mobile client (for example, a tablet). The details of this split are in the tables that follow.

The following table describes the workload split for Smart IT universal client:

 Table

Workload split for Smart IT universal client

Smart IT universal client scenario

Percentage of total concurrent users

Transaction rate (per user per hour)

Update Incident

8%

4

Update Work Order

8%

4

Create Service Request

3%

6

Update Task and Incident

4.8%

5

Create Incident2.8%8
Global Search for Asset and Knowledge Articles2.8%6
Create Broadcast1%6
Create Chat Conversation to Incident5%4
Update Change and Create Task3.8%4
Create Change3%4
Create and Update Knowledge Article2%4
Search Change by ID and View Full Details2%6
Update Change to Closure1%

11

View and Update Asset3.8%4
Bulk-update Asset0.5%3
Create Release0.8%4
Search Release0.3%4
View Decision Tree Knowledge Article0.3%3

On Dashboard page select All filters except 1

0.8%3

The following table describes the workload split for Smart IT mobile client:

 Table

Workload split for Smart IT mobile client

Smart IT mobile client scenario

Percentage of total concurrent users

Transaction rate (per user per hour)

Update Incident

4%

6

Update Work Order

5%

6

Update Task and Incident

5%

6

Create Incident

1%

16

Global Search for Asset and Knowledge Articles1.5%6
Approve Change2%6
Update Change2%4
View and Update Asset2%6

The following table describes the workload split for BMC Digital Workplace universal client:

 Table

Workload split for BMC Digital Workplace universal client

BMC Digital Workplace universal client scenario

Percentage of total concurrent users

Transaction rate (per user per hour)

Create Service Request

18%

4

Create Post

22.73%

5

Search Globally

31.82%

7

View Unified Catalog27.27%6

The following table describes the workload split for BMC Remedy ITSM:

 Table

Workload split for BMC Remedy ITSM

BMC Remedy ITSM scenarios

Percentage of total concurrent users

Transaction rate (per user per hour)

Create Incident via Web Service

1%

51

Inbound Email Based Update of Incident

1%

36

The following tables list the projected number of executions after 1 hour for 2000 users using Smart IT, BMC My IT, and BMC Remedy ITSM.

The following table describes the projected executions for Smart IT universal client:

 Table

Smart IT universal client projected executions

Smart IT universal client scenario

 Projected executions for 2000 total concurrent users
Update Incident640
Update Work Order640
Create Service Request360
Update Task and Incident475
Create Incident440 
Global Search for Asset and Knowledge Articles330 
Create Broadcast120 
Create Chat Conversation to Incident400 
Update Change and Create Task300 
Create Change240 
Create and Update Knowledge Article160 
Search Change by ID and View Full Details240 
Update Change to Closure220 
View and Update Asset300
Bulk-update Asset30
Create Release60
Search Release20
View Decision Tree Knowledge Article15

The following table describes the projected executions for Smart IT mobile client:

 Table

Smart IT mobile client projected executions

Smart IT mobile client scenario

Projected executions for 2000 total concurrent users 
Update Incident480 
Update Work Order600 
Update Task and Incident600 
Create Incident320 
Global Search for Asset and Knowledge Articles180 
Approve Change240 
Update Change160 
View and Update Asset160

The following table describes the projected executions for BMC Digital Workplace universal client:

 Table

BMC Digital Workplace universal client projected executions

BMC Digital Workplace universal client scenario

Projected executions for 2000 total concurrent users 
Create Service Request480
Create Post600 
Search Globally630 
View Unified Catalog780

The following table describes the projected executions for BMC Remedy ITSM:

 Table

BMC Remedy ITSM projected executions

BMC Remedy ITSM scenario

Projected executions for 2000 total concurrent users 
Create Incident via Web Service1020 
Inbound Email-Based Update of Incident720 

BMC Service Level Management and email notification workload distribution

Email notifications were sent in the following instances:

  • When an incident or a service request was created
  • When an incident, a work order, a task, or a knowledge article was updated

BMC Service Level Management targets were also triggered under similar conditions. The following table lists the number of email notifications generated and BMC Service Level Management targets matched for each created incident and service request, and for each updated incident, work order, and task. This workload was executed automatically on the BMC Remedy AR System server.

 Table

Email notification and BMC Service Level Management executions

Scenario

Email count per entry

BMC Service Level Management target count per entry

Create Incident from UC and Mobile

2 to 6

1

Update Incident from UC and Mobile

1 to 3

1

Create Service Request from UC and Mobile

3 to 5

1

Update Work Order from UC and Mobile41
Update Task and Incident from UC and Mobile111
Update Knowledge Article10

Create Change from Browser

1

0

CI normalization and reconciliation workload distribution

During the 1-hour simulation, 7,500 CIs were generated, normalized, and reconciled every 10 minutes. 10% of the CIs were newly created, while the other 90% were updated.

Simulating the workload of 2000 concurrent users

In this test, the following workloads were used:

  • Smart IT, BMC Digital Workplace, and BMC Remedy ITSM
  • 7,500 CIs for the Normalization Engine and Reconciliation Engine

The results are displayed in the following table. Actual entries were created during a 2000 concurrent-user load.

 Table

2000 concurrent-user loads

Entry Type

Number of actual entries created or modified for 2000 total concurrent users (during entire hour)

Incidents created2,880 
Service Requests created1,070
Changes created420
Incidents modified1,990 
Work Orders modified1, 200
Outbound emails68,050 
Inbound emails716 
CIs created64,625 
CIs updated34,590 

Data volume

The following table summarizes the foundation data and application data inserted into the BMC Remedy AR System database prior to starting the tests:

 Table

Data volume of BMC applications of one tenant

Application

Description

Number of entries

BMC Service Request Management

Application Object Template (AOT)

74

 

 

 

 

 

 

 

 

 

Process Definition Template (PDT)

91

Navigational Category

17

Levels

5

Service Request Definition (SRD)

273

Entitlement Rules

52

Matching Entitlement Rule per person

10

SRD for create Service Request with 6 questions mapped to 2 incident fields

1

SRD for create Service Request with 6 questions but no mapping

1

Existing service requests for volume

3,10,200

BMC Incident Management

Incidents

2,60,000

BMC Change Management

Change Requests

19,300

BMC Service Request Management - Work Orders

Work Orders

13,880

BMC Problem Management

Problems

10,000

BMC Atrium CMDB and Foundation

Companies

128

 

 

 

 

 

 

 

 

 

 

 

 

Site

300

Org

96

Support Groups

94

Total End Users

33,964

Total Support Users

16,454

Support Functional Roles

12,823

People Permission Groups

36,781

CIs and Relationships (total)

2,120,000

Business Service CIs

185

Assignment Configuration

314

Service Targets

1045

CIs attached to end user

32574

BMC Knowledge Management

Known Error

14

 How To28,000
 Problem Solution17
 Reference12

Decision Tree1,000

 

 

External Small PDF Documents 120 KB

10,000

External Large PDF Documents 1 MB

1,000


Smart IT Support User configuration - Restricted Supports Users Access

For 1908 release performed 1400 user load test with Smart IT Restricted users. For these Restricted user new Subquery algorithm for Row-Level security filed was selected.

The new Subquery algorithm for Row-Level security (RLS) field improves performance (response time) by filtering database content based on user-specific roles. 

Subquery algorithm can be used on a form where performance issue is observed while fetching data from RLS-enabled fields. For example, querying the database might take more time for users other than administrators. In this case, using the Subquery algorithm fetches the search results faster.

Steps to identify forms and change algorithm

  1. Capture API-SQL Logs for the use case with the high response time (Steps to Enable Logs)
  2. Get the list of longest running API Forms.
  3. For the Longest running form/s from Row Level Security Fields panel on the Definitions tab in the Remedy Developer studio select Algorithm as “Subquery” (RLS Subquery Enhancement)

Note:

  • Changing the RLS algorithm to 'Subquery' for all the forms is not recommended as it might have negative performance impact.
  • For View and Union forms, change algorithm for all the regular forms participating in View/Union.
  • For UNION forms after changing algorithm, goto to “SHR:Union_ConfigurationConsole” form, select Union form name from “Implementation Area” drop down and Click on “Build/Rebuild Database Union Structure”, to complete migration of Union Form
  • For Join Forms, change algorithm for Join Forms, changing algorithm for participating form is not required.
  • For BM.Core* forms make above mentioned changes only in “Base Development Mode”
Was this page helpful? Yes No Submitting... Thank you

Comments