ca.portal.admin

Re:Re: R14.1 vs. R16 ADS performance

Discussion created by ca.portal.admin on Mar 2, 2006
Kay -

We have seen a notable increase in 14.0 VS. 16.0..
For us, it is especially noticeable in local mode batch retrieval.

In fact, we have a test sample program we are using that is almost
completely database work (no other real business logic code).
We've seen large increases with this test program.
We've seen large, (but not as large as the sample program) increases
with
real-world batch testing.

We are working with C.A., who has been very earnest in working on a
performance APAR for us.
It's still work-in-progress as we are going through an iterative process
of
re-coding and re-testing.
We are seeing improvements as a result, but not quite where we want to
be,
just yet.
So, you may not see this published for another month or two.
The APAR, in it's current form, is enormous (under 2000 lines of VERS
and
REPS).

IDMSDBMS was practiacally split into two because it is so big now.
The two major CSECTS are IDMSDBMS and IDMSDBM2.
It appears there is a significant amount of debugging code in both of
these
that is really only useful in certain specific circumstances.
C.A. is taking the stance that we are executing a lot of instructions
for
something that is of little value most of the time.
They can always Option-APAR this code right back in if it's needed for
troubleshooting a problem.

I know some of you out there said you saw no increase going to R16.
I wish I could have said the same thing.
However, after almost 60 different tests so far since January, there is
no
denying the evidence.
It's ""right-in-your-face"".

We spent the first several days ruling out things that might have been
set-up incorrectly or missed during the install.
I'm pretty sure we have been testing on a level playing field now.

We, too, are kind-of stuck in Limbo.
Based on extrapolations, we wouldn't finish our nightly batch by
morning's
deadline.
So, we are staying put for the time being.

Jon Gocher.


----- Original Message -----
From: ""Rozeboom, Kay [DAS]"" <KAY.ROZEBOOM@IOWA.GOV>
To: <IDMS-L@LISTSERV.IUASSN.COM>
Sent: Thursday, March 02, 2006 3:09 PM
Subject: R14.1 vs. R16 ADS performance


After upgrading our test CV's from R14.1 SP6 to R16 SP2, most dialogs
are using .01 additional second of CPU, according to PMAM report 01.
This may not sound like much, but it would have a significant impact in
production. We are trying to figure out if this is:

1) An artifact of the testing process. (We no longer have an R14.1
test CV, so cannot repeat the test at that release.)
2) Something done incorrectly during the upgrade.
3) An actual increase in CPU required for ADS in R16.

We have storage protection on at the system level, and off at the
program level for ADSOMAIN and ADSORUN1. This did not change with the
upgrade. (I checked.) We are not using the new HPSPO.

Has anyone else experienced an increase in ADS CPU use after upgrading
to R16?

Kay Rozeboom
State of Iowa
Information Technology Enterprise
Department of Administrative Services
Telephone: 515.281.6139 Fax: 515.281.6137
Email: Kay.Rozeboom@Iowa.Gov
This communication is intended for the use of the recipient to which it is
addressed, and may contain confidential, personal and or privileged
information. Please contact us immediately if you are not the intended
recipients of this communication, and do not copy, distribute, or take
action relying on it. Any communication received in error, or subsequent
reply, should be deleted or destroyed.

"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Common Signon
"Hi Dan,
If I missed this concern mentioned earlier in this discussion thread, excuse
me, as that concern that would be performance.

Poor man's DDS also called the DC to DC communications facility is a great
idea from a architecture stand point as it comes with IDMS. Make sure you
benchmark it if performance is a concern. As I recall, like DDS, it has some
longer path lengths and additional CPU consumption than the DC Front end for
UCF.

It sounds like I am with Mr. Brady as I would recommend the DC front end for
UCF as one can programmatically call the UCF front end module and have
control over who runs where not to mention the UCF defs are table-driven.

Wishing you and all a great weekend,
Joe Perkins

Outcomes