One World Performance Issues

[lgould]

We are currently using a 820 AS/400 4 way as our enterprise server and =
running XE service pack 14.1. When running OW interactive applications we =
see response times varying from 2 seconds to 2 minutes. There is no =
specific time of day when this happens and sometimes two different PCs =
running at the same time have drastically different response times. You =
can run the application on the same PC minutes apart and have a very quick =
response one time and not the other. We are averaging a .20 second =
interactive response time on our AS/400 and see no heavy CPU utilization. =
Does anyone have any suggestions.=20

 

[Darquise_Nicol]

We were having similar response and we found that our memory pool for
Qserver subsystem was to low. For each active OneWorld user you should
allocate 15MB of memory.
ie: 10users x 15 = 150MB of memory should be allocated to Susbsystem
Qserver

Darquise Nicol
Independent Consultant

Xe SP14.1, AS400 720
NT4 for our WebServer and Apps Server, SQL7, Websphere 3.02 upgrading to
3.5.3 (hopefully next week)




lgould
<[email protected] To: [email protected]
> cc:
Sent by: Subject: One World Performance Issues
owner-jdeowdevml@j
delist.com


08/15/2001 05:16
PM
Please respond to
jdeowdev






We are currently using a 820 AS/400 4 way as our enterprise server and =
running XE service pack 14.1. When running OW interactive applications we
=
see response times varying from 2 seconds to 2 minutes. There is no =
specific time of day when this happens and sometimes two different PCs =
running at the same time have drastically different response times. You =
can run the application on the same PC minutes apart and have a very quick
=
response one time and not the other. We are averaging a .20 second =
interactive response time on our AS/400 and see no heavy CPU utilization. =
Does anyone have any suggestions.=20




--------------------------

 

[rjjump]

Memory pools are definitely a good place to start. You can adjust them in
WRKSYSSTS, you can also see the faulting rates from that screen. If the
faulting rates are not much higher in any of the pools than others, than
that is probably not the issue.

Since it is sporadic I might suspect some network settings, such as DNS
setup. It might be trying to resolve a name and just be waiting on a
response, (which if things aren't setup right can sometimes be a while and
sometimes be very quick). In Client Access setup there is a setting which
determines how often a lookup is done. Changing this might help. You
might also try manually setting hosts files in a few of the PCs and see if
the problem goes away for those workstations, not sure if that is practical
or not in your environment, but it might help isolate the problem.

Also make sure you are up to date on PTFs and fix packs. I remember a
while ago there was an issue with a response being held up until it timed
out, then it was resnt and all was fine.

There are some tuning recommendations in the redbook from last year. I
believe most of them are still valid for WIN32 type clients. I think there
was a mistake and the ODBC setting for "cache package locally" was left
off. This is a minor point and wouldn't explain the difference from 2
seconds to 2 minutes, but we saw about 5% difference when turning it on and
every little bit helps. There is an HTML tuning tips document available as
well from the IBM JDE support site, where you can find the redbook &
recommended PTF information.

In another post someone mentioned that it could be different lookups/apps,
causing different SQL calls, some taking longer than others. This makes
sense too. I would start with the simpler steps, memory and basic tuning,
then move to the network, (which probably requires a little work with a
sniffer), then move to the database and working with DBMON or debug logs.

Best of Luck!

Rob Jump
Sizing Specialist
IBM/J.D. Edwards International Competency Center
303-334-1054
[email protected]


Darquise_Nicol <[email protected]>@jdelist.com on 08/16/2001
10:16:30 AM