Skip to content
CA Application Performance Management - 9.7
Documentation powered by DocOps

CA APM Client Requirements

Last update June 27, 2018

CA APM has requirements for clients.

CA APM Clients

CA APM provides these client components:

  • Workstation
  • WebView
  • Command Line Workstation
  • CEM console

CEM Console

The CEM console is a web browser based client that a standalone Enterprise Manager running Enterprise Manager services or a MOM provides. The CEM console does not require any special capacity planning or sizing.

Workstation Resource Consumption on the Enterprise Manager

Workstation connections to an Enterprise Manager are not resource-intensive, and there is no practical, software-based limit to the number of Workstations that an Enterprise Manager can handle. Workstation session resource consumption depends entirely on what tasks the Workstation users are doing. For instance, many users can view live metrics concurrently with little resource consumption. However, many users triggering frequent Transaction Traces on large transactions, or requesting thread dumps, consume a large amount of memory on the Enterprise Manager.

A clamp on the number of concurrent Workstation connections is defined in the apm-events-thresholds-config.xml file. This clamp is the introscope.workstation.max.users property. The default value is 40, which is a conservative value. You can increase the value by basing the configuration on Enterprise Manager resource availability and expected Workstation user behavior.

User activity through Workstation clients consumes the following Enterprise Manager resources, from most to least important:

  1. Heap memory
  2. Network bandwidth
  3. Disk storage and I/O
  4. CPU

Workstation and MOM Performance

In a clustered environment, make all Workstation, CLW, WebView, and CEM console connections to the MOM and not to any Collectors for these reasons:

  • A direct Workstation connection to a Collector competes with the MOM query load, and can reduce the cluster responsiveness.
  • Processing client queries reduces Collector metric capacity.
  • All metric data visible through the Collector connection is visible through the MOM. Therefore, there is no practical reason to connect to a Collector to view the data.
  • An Introscope user cannot view the application triage map when the user Workstation is directly connected to a Collector.

The same Workstation scalability considerations applicable to standalone Enterprise Managers are applicable to the MOM. However, there is an additional consideration: The distribution of metric queries across the Collectors also has an impact on MOM responsiveness and scalability. If a query requires metric data from multiple Collectors, then the MOM must receive the required metrics from all participating Collectors before returning the query results. One overloaded Collector can therefore reduce the cluster responsiveness.

Important! Workstation performance problems can occur if all the Workstation connections involve active users, and all their queries require the data from the same Collectors. In that case, the users can experience sluggish performance due to the Collectors own internal limitations on simultaneous historical queries.

Top N Graphs

Top N is a way to qualify a graph on an Introscope dashboard so that only the Top N metrics display. You pick the Top N number. Processing Top N graphs requires many Enterprise Manager resources. For example, you can set up a metric group that queries your system for the average response time of 100,000 servlets. On a dashboard, you have a graph that displays the five slowest servlets. The Enterprise Manager must subscribe to and process the data for all 100,000 servlets to determine the five slowest.

Top N graph calculators query many metrics, but return only a few metrics to the client. For this reason, Top N graph calculators do not benefit from CA APM large-query optimizations. 

Note: Use Top N graphs sparingly or limit the query resource consumption. When you make a Top N request, all data is provided in real time. This situation places a large resource demand on your Introscope system.

If Top N and CLW queries create ongoing problems in your environment, limit the query resource consumption. Add these two clamps properties to the IntroscopeEnterpriseManager.properties file to limit query resource consumption:

  • introscope.enterprisemanager.query.datapointlimit

Clamps the number of data points that the Enterprise Manager reads from the SmartStor.

  • disk.introscope.enterprisemanager.query.returneddatapointlimit

Clamps the number of data points that the Enterprise Manager sends across the network.

Application Triage Map and Concurrent Workstation Users

Each time the Workstation draws the application triage map, it must query the Enterprise Manager for the needed data. In most instances, these queries are trivial and have no noticeable effect on the Enterprise Manager. However, for larger application triage maps containing hundreds of map nodes or more, these Workstation queries can be quite Enterprise Manager CPU intensive. Therefore, CA Technologies recommends that Introscope users have no more than eight concurrent Workstations actively requesting application triage map data at any given time. Since application triage map queries are mainly Enterprise Manager CPU intensive, more processing resources allow for more concurrent application triage map users.

WebView Browser Guidelines

The WebView client presents the customizable Console dashboards and other Workstation tree views in a browser interface. In WebView, the browser client could experience a performance degradation if the following capacity guidelines are not followed:

  • The WebView client browser can display up to 20 charts (maximum) per dashboard on our reference client hardware. Each chart can handle 25 metrics (maximum) in a dashboard without experiencing a performance degradation. Total: 500 metrics per dashboard.

    Note: If you are experiencing browser performance issues while viewing your dashboards consider breaking large dashboards into smaller, interlinked dashboards.
  • Excessive numbers of charts (or metrics in a chart) can slow down the initial dashboard page response time and subsequent updates to live data. To avoid this problem, do not create dashboards with too many charts. Try to limit metric load per chart with more selective metric group associations or TopN queries.

To improve the browser performance, consider the following information:

  • Charts without legends have much better performance footprint than charts with legends.
  • The Firefox browser performs much better than Internet Explorer 9.
  • The Internet Explorer 8 browser is known to have performance issues while running HTML 5 based applications compared to current browsers and is not recommended. If IE 8 is used, you can benefit from reducing the dashboard contents by splitting large dashboards into smaller ones.

WebView Server Capacity

CA Introscope<reg> clients let users view the metrics that have been collected in their application environment. The metrics are delivered to clients using metric queries, which consume memory. In WebView, the application triage map and the SOA dependency map consume more memory as compared to other metrics queries. In addition, the application triage map uses more CPU resources on the WebView Server when there are concurrent users interacting with the map.

The Application Triage Map and SOA Dependency Map metric queries consume the heap memory on the server. You can increase the server capacity by increasing the heap allocation to the WebView server.

Note: On the reference server hardware, the WebView server can handle up to 25,000 metrics. This benchmark was tested on an MBX Rev. D server with Intel Xeon X5460 3.16 GHz and 12 GB RAM. The server was running Red Hat Enterprise Linux on a 5.7 64-bit system. The server heap size was set to 4 GB.

WebView Server Guidelines

For WebView, use the following server guidelines:

Memory

Consumption of memory is distributed between the core Enterprise Manager and the WebView server for queries originating from WebView clients. You have the option of installing the WebView server as follows:

  • During the Enterprise Manager installation.
  • As a separate installation.

Installation

When you install the WebView server during the Enterprise Manager installation, WebView is run as a separate JVM process. This WebView installation does not benefit from CA APM query scalability optimizations.

To run WebView and the Enterprise Manger on the same server, you must have:

  • 16 GB of RAM
  • 8 CPU Cores
Important! To benefit from CA APM client scalability optimizations, install WebView as a separate installation.

SOA dependency map

To prevent the SOA dependency map from affecting the WebView server performance and operations, you can limit the size and complexity of the dependency map nodes and map edges by configuring the following properties:

  • com.wily.introscope.soa.dependencymap.ui.view.nodecount
    Specifies the maximum number of map nodes that display on the SOA Dependency Map.
  • com.wily.introscope.soa.dependencymap.ui.view.edgecount
    Specifies the maximum number of map edges that display on the SOA Dependency Map.
Note: For more information, see the SOA-Specific WebView Properties in the SOA Implementation Guide.

Optimization

To optimize the scalability of the client, perform these tasks:

  • Provide the WebView server with at least 4 dedicated CPU cores.
  • Allocate as much heap memory as possible to the WebView server, and in addition:
    • Install the WebView server on a 64-bit operating system, use the 64-bit installer, which installs the 64-bit JVM.
    • Help ensure that the maximum heap is no more than the available RAM minus 1 GB.

You can adjust the WebView server heap allocation by changing the lax.nl.java.option.additional property in the Introscope_WebView.lax file.

A WebView server does not require a dedicated I/O subsystem.

Command Line Workstation

The CLW allows you to send command line and script-based metric queries and other administrative commands to an Enterprise Manager. By design, the CLW is a light-weight program that delegates significant client processing to the Enterprise Manager. Thus, the CLW does not participate in the distributed resource consumption that provides CA APM query optimizations.

Concurrent CLW queries that return numerous metric data cause the Enterprise Manager to use all available heap memory.

When frequent and large CLW Top N and CLW queries create problems in your environment, limit query resource consumption. Add these two clamps properties to the IntroscopeEnterpriseManager.properties file:

  • introscope.enterprisemanager.query.datapointlimit
    Clamps the number of data points that the Enterprise Manager reads from the SmartStor.
  • disk.introscope.enterprisemanager.query.returneddatapointlimit

Clamps the number of data points that the Enterprise Manager sends across the network.

Clamps to Limit Top N Graph and CLW Query Resource Consumption

Important! Clamps restrict functionality. When clamp thresholds are hit, queries do not return accurate data. Use the clamps only when you have no other methods to maintain the stability of your monitoring environment. Increasing or upgrading Enterprise Manager resources or tuning queries to include only necessary data are better solutions than setting clamps.

The introscope.enterprisemanager.query.datapointlimit property clamps the number of data points that the Enterprise Manager reads from the SmartStor disk. Use this clamp when disk contention with large historical queries has a detrimental effect on SmartStor duration, and therefore on Enterprise Manager capacity.

The introscope.enterprisemanager.query.returneddatapointlimit property clamps the number of data points the Enterprise Manager sends across the network. This clamp limits the amount of data that an Enterprise Manager processes for a query. Use this clamp to prevent Enterprise Manager memory errors.

These clamps apply to all queries, including Top N graphs.

Optimal values for these clamps are based on these factors:

  • Available resources
    • Disk I/O performance
    • Heap memory availability
  • Expected query load

If you experience Top N or CLW problems, investigate the supportability metrics. After you confirmed that query caused the problem, vary the clamp values in a test environment.

Follow these steps:

  1. Examine these supportability metrics to determine the query load at the time a disk contention or memory problem occurred. 
    *SuperDomain*|Custom Metric Host (Virtual)|Custom Metric Process (Virtual)|Custom Metric Agent (Virtual)|Enterprise Manager|Internal:Number of Metric Data Queries per Interval
    *SuperDomain*|Custom Metric Host (Virtual)|Custom Metric Process (Virtual)|Custom Metric Agent (Virtual)|Enterprise Manager|Internal:Query memory in transit (bytes)
    *SuperDomain*|Custom Metric Host (Virtual)|Custom Metric Process (Virtual)|Custom Metric Agent (Virtual)|Enterprise Manager|Internal|Query:Queries Exceeding Max Data Points Read From Disk Limit Per Interval
    *SuperDomain*|Custom Metric Host (Virtual)|Custom Metric Process (Virtual)|Custom Metric Agent (Virtual)|Enterprise Manager|Internal|Query:Queries Exceeding Max Data Points Returned Limit Per Interval
    *SuperDomain*|Custom Metric Host (Virtual)|Custom Metric Process (Virtual)|Custom Metric Agent (Virtual)|Enterprise Manager|Internal|Query:SmartStor Queries Duration (ms)
    *SuperDomain*|Custom Metric Host (Virtual)|Custom Metric Process (Virtual)|Custom Metric Agent (Virtual)|Enterprise Manager|Internal|Query:SmartStor Queries Per Interval 
    *SuperDomain*|Custom Metric Host (Virtual)|Custom Metric Process (Virtual)|Custom Metric Agent (Virtual)|Enterprise Manager|Tasks:SmartStor Duration (ms)
  2. If necessary, add and configure the clamp properties.

  3. Use a test environment to test the effect of the clamp values on your metric store and your queries.
    1. Copy a production SmartStor to a test environment.
    2. Alter the Top N graph and CLW query time windows to match the period of the copied SmartStor data.
    3. Execute the Top N graphs and CLW queries to request the largest data sets your environment requires. Verify that the queries trigger the relevant clamps.
    4. Repeat Steps 2 and 3c until the clamps trigger correctly.
Was this helpful?

Please log in to post comments.