Automic Workload Automation

Expand all | Collapse all

Java UI performance constrained by CP

  • 1.  Java UI performance constrained by CP

    Posted 08-28-2018 12:23 PM

    Recently, we observed a problem we had not noticed before: users were complaining about poor Java UI (UCDJ) performance, and we discovered that only some users were experiencing poor performance. It seems to be dependent on the communications process (CP) to which the user's JUI is connected.

     

    1. Has anyone else seen this before? If so, how did you fix it?
    2. How, exactly, does the an agent, JUI, or other client app decide on (or get assigned) a particular CP?
    3. We understand that there is some sort of load balancing going on. Is this dependent on the usage of the CPs, the number of connections, or some combination of factors?
    4. Is there a way to segregate certain types of connections onto dedicated CPs?

     

    TIA.



  • 2.  Re: Java UI performance constrained by CP

    Posted 08-31-2018 04:33 AM

    I have an update on this problem. It appears that this is a new bug added in v12.0.5. It is expected to be resolved in 12.0.5 HF3, due to be released next week.



  • 3.  Re: Java UI performance constrained by CP

    Posted 09-25-2018 05:26 AM

    12.0.5 HF3 is now available.



  • 4.  Re: Java UI performance constrained by CP

    Posted 09-25-2018 05:50 AM

    My users are constantly complaining about poor JAVA UI performance. Period!



  • 5.  Re: Java UI performance constrained by CP

    Posted 10-16-2018 01:08 AM

    I am not quite sure about the Java-UI but the OS-agents are working this way:

    The agent gets a list of all CPs (in the same net area) with the number of connections and connect to all CPs. Then it closes all open connections except of the one with the lowest number. The CP load is not considered because it can change to quickly. As far as I know the Java-UI is soing something similar.

     

    You can segregate certain types of connections onto dedicated CPs by using Net Areas. We are you using it to separate our agents from our normaler users (Java-UI) and our technical users (CallAPI und Java API). But from my own experience I can say that one should not exaggerate with the number of network areas... Currently we are using V11.2 (and V10). When we update to V12.x, we will possibly redesign it and only separate agents from users.