topic Re: ACMS performance issue in Operating System - OpenVMS

ACMS performance issue

Stanley F Quayle — Tue, 07 Feb 2006 13:55:55 GMT

The following problem came from a customer. They're running ACMS V4.4B on an Alpha V7.3-2. Their part of the code is written in C.

What we have found that considerable time (1/2 to > 1 second, sometimes 4 to 5 seconds) is spent within ACMS and we need to find out what is causing this delay. Here is more detail:

When running task calls through the adapter at low volume level, we are still seeing exceptions showing response times over a 1/2 second, and sometimes over a second. We're running just one server process in ACMS, but at low levels with only a single instance of the adapter running, that shouldn't matter. When we correlate the task start and end time from the ATR with the times in the adapter log surrounding the API call, we find that the majority of the time is spent after the task completion and before the adapter gets notification back from the API.

What can we do to try to account for this time that's occuring after task completion and before return from the API?

Re: ACMS performance issue

Wim Van den Wyngaert — Wed, 08 Feb 2006 02:55:29 GMT

Don't know ACMS but there is a version 4.5 for which I didn't find the release notes on the internet.

So, I'll post them here.

Wim

Re: ACMS performance issue

Bennett_2 — Tue, 11 Apr 2006 08:43:17 GMT

Between the start and end time for the task it sounds like there is I/O getting performed in the ACMS SP server process. It could be that the "bottleneck" is in the I/O which is getting performed to the RMS, DBMS, Rdb (or other) database used in the SP.

Disk bottlenecks, possible locking/contention, Rdb optimization to sequential searches, and other misc bottlenecks are worth looking into.

Re: ACMS performance issue

Stanley F Quayle — Tue, 11 Apr 2006 15:29:14 GMT

With HP's help, the client was able to trace the problem to his code. So, "never mind"...

Re: ACMS performance issue

Stanley F Quayle — Tue, 11 Apr 2006 15:31:06 GMT

Thanks for the help.