Automic Workload Automation

Expand all | Collapse all

Using Net Areas to segregate CP connections by type

Jump to Best Answer
  • 1.  Using Net Areas to segregate CP connections by type

    Posted 08-30-2018 07:25 AM
    Edited by Jason McClellan 10-31-2019 11:47 AM

    Since upgrading to AE v12.0.5, we have been suffering from a new problem wherein Java UI performance is constrained by CP. Some CPs are overloaded, while others are running fine and could easily handle more connections. Connecting client programs (agents, Java User Interface users, and applications based on the Java APIs) continue to connect to a CP that is already overloaded, rather than connecting to a less-burdened CP.

     

    We are looking into possible ways to address the problem, and one idea we have come up with is to use Net Areas to segregate CP connections by the type of connecting client. E.g.,

    • Net Area 1: Agents
    • Net Area 2: Java User Interface clients
    • Net Area 3: Java Application Interface clients
    • Net Area 4: Automic Web Interface (AWI) server(s)


    Has anyone tried this before? Does it work? Are there any special things to be aware of?

     

    Also, are Net Areas relevant to Java Communications Processes (JCPs)?

    Note:  image restored from legacy jive instance 10/31/19  @Jason McClellan



  • 2.  RE: Using Net Areas to segregate CP connections by type
    Best Answer

    Posted 10-25-2019 08:22 AM
    Edited by Michael Lowry 12-11-2019 02:26 AM
    Based on the approach described above, we implemented a second net area for one particular external application that uses the AE Java APIs. This app often puts a high load on the Automation Engine, and we have had success in preserving engine & GUI performance by moving this app to its own dedicated CPs.

    Here is an overview of our net areas:
    • Primary net area (CPs 1-5) 
      • Agents
      • JUI
      • AWI
      • Java API app #1
    • Secondary net area (CPs 6-10)
      • Java API app #2

    Java API app #1 is under active development, and may grow soon in the number of API calls it makes. If we find that it begins to put a high load on the AE, we may move it to a dedicated net area too.