R11 Management Command Center Scalability Tests Revised July 17 2006 -

r11Management Command Center

Scalability TestsRevised July 17 2006

-

2 © 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.

Objectives

- The objective of this test is to generate many status changes and verify the accurate status is seen in the user interfaces.

- This simulates status storms that may be generated by CA applications such as Agent Technology DSM managing large numbers of managed objects

- Analyze memory utilization when launched from Terminal services sessions

- Analyze the response time with different number of MCC Sessions

Overview


Setup

Cluster Node A Cluster Node B

Highly Available Ingres MDB

MCC Client on a non clustered node


Highly Available

- MDB and Worldview Manager component is highly available running in a Microsoft Cluster Environment


Status Changes

- Status Changes are instrumented using a custom built WV Stress utility (not available to clients)

- Updates status in an orderly manner to verify status changes

- Objects are created with specific naming standards to provide for mass updates and status tracking


WV Stress Utility


2dmap display – IP_Subnet


2dmap display – Windows_NetServer


MCC Display – IP_Subnet

Confirms 24101 Objects


MCC Display

Each IP_Network has 240 objects

Test 1- Memory Utilization


Test 1 – Objectives

- The main objective is to identify Memory Utilization when MCC Client is launched from Windows Terminal Services Client (Remote Desktop)


Test 1 Plan

- Establish 20 Terminal Services Client connections

- 10 connections from each server

- Launch 1 MCC session from each session

- Launch Classic 2dmap

- Generate 8000 status updates

- Review Memory utilization


Memory Usage after 8000 Updates

Terminal Server A



Terminal Server A



Terminal Server B



Application SessionMemory (mb)

Peak

MCC Clients Server A 10 92

MCC Clients – Server B 10 72.5

Classic CATNG2d – Server A 10 51

Classic CATNG2d – Server B 2 66

Classic 2dmap CA Notify – Server A 10 11.5

Classic 2dmap CA Notify – Server B 11.5

Terminal Client Session 10 4

Terminal Client Session 10 4.5


MCC Display after Updates


Conclusion

- Memory Utilization for 24000+ MDB (CORE) objects

- 100 mb for each MCC Client session

- 70 mb for the Classic 2dmap

- The MCC Client size will vary depending on the display

Test 2- Propagated Severity

- Classic GUI


Test 2 - Goals

- The main objective is to analyze the time it takes to update 8000 status changes for different User Interfaces


Test 2 – Test Plan

- Create 8000 Windows System Agent objects with unispace, host and ip_subnet objects.

- Stop DSM services to prevent any unsolicited status changes

- Launch 4 MCC clients sessions.

- 2 MCC clients from each Terminal Server

- Update status from Normal to Critical

- Analyze time it takes to update the status changes

- Verify Severity Propagation and status reflected correctly for all objects in MCC and 2dmap running in non delta mode


MDB - WV Objects


Report Showing Number of Objects

8000 System Agents


Status Display Rule – Maximum Severity


2dMap at Start


MCC Display at Start


Generate Status Changes

Start of 8000 updates


2dmap Session - Completed

3 mins 51 seconds to update and correctly display 8000 status


MCC Client - Completed

MCC Client reflects correct status 5 mins after 2dmap


Test 2 - Conclusion

- With 4 mcc sessions and 8000 status updates

- 2dmap reports status changes almost instantly as the MDB is updated

- MCC clients take 5 mins more than 2dmap to reflect all status updates

- As the number of MCC sessions goes up, the time it takes for MCC to reflect all changes will increase as well.

Test 3- Database Updates


Test 3 - Goal

- The main objective is to analyze the time it takes to update MDB to process 8000 status changes.



- Generate 8000 status.

- Analyze the time it takes for MDB Updates as a result of 8000 status changes.

- severity propagation for Windows Hosts

- severity propagation for IP_Subnets


MDB - WV Objects


Status Display Rule – Maximum Severity


SevProp - Levels

This shows Windows Host is 6 levels down


Generate Status Changes


DB Updates

This shows the rate of Propagated Severity Database updates as a result of status change

Start Time Query Time No. Of Host IP Subnets Elapsed Time DB Updates Rate / Sec3 Levels Down

18:55:53 58 1

18:56:24 547 7 31 47.32

18:56:57 1220 15 33 61.18

18:57:28 1843 24 31 60.29

18:57:59 2418 30 31 55.65

18:58:30 2951 37 31 51.58

18:59:01 3143 37 31 18.58

18:59:33 4440 56 32 121.59

Average No DB Updates Per Second 59.75

220

Calculations are based on 3 levels down. In theory there may be more 3 updates for each change in status. One for System Agent, Unispace and the Host object. In addition, there will be one for IP_Subnet and IP_Network. These updates have been discarded for this test.

Test 4- MCC Clients Scalability


Test 4 - Goals

- Launch large number of MCC sessions and classic 2dmap

- Analyze the time it takes to reflect the changes in the UI



- Launch 23 MCC client sessions

- 10 Terminal Services sessions from Server A.

- 10 Terminal Services sessions from Server B

- 3 Terminal Services sessions from Server C

- Generate 8000 status changes

- Verify the status changes reflected correctly on all sessions

- Analyze the time it takes to reflect status changes in MCC client and classic 2dmap


RMI_Server Sessions1 SessionID: <monitor session>

2 SessionID: 055fc21a-8986-403c-85ed-99745b0057ed

3 SessionID: 269e0c70-a1e5-457e-9b07-952dfbdf676a

4 SessionID: 2d089434-af0d-4037-8670-60fcb7818451

5 SessionID: 3522ff38-6145-4fa1-8b9e-60c0a0963392

6 SessionID: 3633ec42-7fcb-4fc5-bbe2-3060ffacbe27

7 SessionID: 4483b6d2-3113-4b83-bd72-08c52ae91b59

8 SessionID: 52d28c35-cc75-4c6b-b372-c4c56f4edc2c

9 SessionID: 6ac0dad8-9a81-442a-a9c3-7325c1b4f9e0

10 SessionID: 76ae2423-1eac-4c11-8fad-dcf30a385f11

11 SessionID: 81a95bba-3974-4b10-b5c1-389f666e1574

12 SessionID: 837f3e5e-4a35-4b8c-a838-f10876b4303e

13 SessionID: 8aae6484-ebb3-46d1-8112-4323afa1ee78

14 SessionID: a5589a50-e697-4ebc-b867-2c1d42dfef7c

15 SessionID: a6ad00fc-0a44-490c-8441-56f641b4bedc

16 SessionID: ab25ab4b-482a-492e-83ac-636038aa6bc5

17 SessionID: ac2c8632-d8f6-421a-87d4-83af336d4b0d

18 SessionID: b2edb56c-b419-4065-95a1-a2a9f56eeacb

19 SessionID: b6320656-c38b-41ee-8ba6-cca34b0c9af7

20 SessionID: c15a521f-252b-43b7-baa7-391d92865271

21 SessionID: cb8344e1-580a-4375-b740-e20390b0b8cb

22 SessionID: e2518a4f-a8cc-474f-9a17-d5630af03d70

23 SessionID: f06b443b-91ef-4cb9-9d1e-e12c1af14b2d

24 SessionID: f9a33422-26e0-48d9-92d7-2940999aae79

25 SessionID: faf3d81c-e333-4a72-9cbc-aeeae5dd34ce

This confirms 23 MCC Client sessions


Status Changes - Start


Status Changes - End

330 Seconds to generate 8000 status changes

Update status to change the severity to Warning


2dmap - End

Shows all status changes reflected instantly


MCC Client - Server A – Updates in Progress

Approx 15 mins to reflect status changes on 23 MCC Clients


MCC Client - Server B – Updates in Progress

Same number of IP_Subnet as Server A


MCC Client - Server A – End


MCC Client - Server B – End

Approx 17 mins to reflect status changes on all 23 MCC Clients


CAM Stats – At Start


CAM Stats – During Updates


CAM Stats – At End


CAM Stats – MCC Clients

CAM Stats Analysis for 23 MCC Clients

Server A Messages Sent

Server B Messages Sent

Start 115827 115798

End 2045537 2045524

Messages Sent 1929710 1929726

Average number of Messages Sent per Second as reported by CAM

2217


Conclusion

- 2dmap

- Status changes reflected instantly

- MCC Client

- The time it takes depends on the number of MCC Client sessions. This is due to the number of messages that need to be sent from WV Manager via CAM to all MCC client sessions

- Status changes reflected consistently all MCC sessions.- MCC Session 23 will show the same status as MCC Session 1

R11 Management Command Center Scalability Tests Revised July 17 2006 -

Documents

Transcript of R11 Management Command Center Scalability Tests Revised July 17 2006 -