Verified Answers

If an answer to your question is correct, click on "Verify Answer" under the "More" button. The answer will now appear with a checkmark. Please be sure to always mark answers that resolve your issue as verified. Your fellow Community members will appreciate it!  Learn more

  • State Verified Answer
  • Replies replies
    10
  • Subscribers subscribers
    203
  • Views views
    934
  • Users 0 members are here
  • Locked Locked
Related
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Tuning OBM for 100+ concurrent UI sessions

ladroege

Hi all,

in an HA setup with 2 single servers, both configured for GW&DPS we face significant UI performance degradation when more than 15-20 users are logged in concurrently. I tried to manually adapt some of the process memory settings, but I am not sure, which of these processes would be the main culprit for the slowdown (up to UI messages, that the server does not respond).

Is there a best practice guide to tune OBM for a higher number of UI sessions? We have 44GB of memory in each server and about 22k CIs currently in the RTSM.Which process typically slows down UIs and what is an acceptable heap usage in the corresponding performance graph for the OBM servers?

Thanks in advance for any sharing of best practice or tuning hints.

Best regards,
Lars Droege

Parents
  • 0  

    Please take a look at https://softwaresupport.softwaregrp.com/doc/KM03801492. OBM supports up to 200 concurrent session per GW. But the performance depends on the CPUs mainly for the user session. Make sure your CPU number matches the deployment that you have and if needed add additional. Also make sure the LB is setup as per the guides using stickiness by IP. The process that runs the application is the MercuryAS on the GW so more memory should be there. 

  • 0 in reply to   

    Hello Rosen,

    Thank you for your reference to the sizing guide.. At the moment we do have 12 CPUs on both "Single Servers" of the HA setup. Adding some more Memory to the Application Server helped the situation at the moment.

    One reason for the high load may be the usage of large views for some operators. The guide recommends not to use views with more than 3000 CIs but for some roles we currently have 10k or even 14k CIs in a view. Can this be better supported with more memory or CPUs or is this a general problem that we need to fix (split the views)?

    Best regards,

    Lars

  • Verified Answer

    +1   in reply to 

    OBM can handle views even up to 20K CIs.

    each GW can handle up to 120 concurrent users, but depends on your deployment levels, you may need more than 12 CPUs... I think 16 is better...

Reply

  • Verified Answer

    +1   in reply to 

    OBM can handle views even up to 20K CIs.

    each GW can handle up to 120 concurrent users, but depends on your deployment levels, you may need more than 12 CPUs... I think 16 is better...

Children
  • 0 in reply to   

    Thank you Asaf,

    unfortunately it seems like there is no clear metric or message that could point us to the actual bottleneck, right?

    We could add more CPUs if needed, but for the moment just based on your "feelings", not based on measurements that would clearly indicate a CPU resource problem.

    The OS level CPU load did not look too high when we faced the slow response times...

    If you know of any further analytic tools for GW performance, I would be happy to try them.

    Best regards,
    Lars

Resources

Support
Documentation
Learning Services
Partner Programs
Privacy
Compliance
Help
Company
Privacy Policy
Terms of Use
Cookies Preferences
Accessibility
Anti-Slavery Statement
Support
Contact Us
Careers
Code of Business Conduct and Ethics
The opinions expressed above are the personal opinions of the authors, not of OpenText. By using this site, you accept the Terms of Use. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.), Hewlett Packard Enterprise Company, or Micro Focus. As of January 31, 2023, the Material is now offered by OpenText, a separately owned and operated company. Any reference to the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks is historical in nature and the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks are the property of their respective owners.