Re: RSE performance against very large source files

sounds like some PTFs may have been applied 8^)

Thanks,
Tommy Holden



"Dave Shaw" <daveshaw@xxxxxxxxxxxxx>
Sent by: wdsci-l-bounces@xxxxxxxxxxxx
02/08/2008 08:08 AM
Please respond to
Websphere Development Studio Client for iSeries <wdsci-l@xxxxxxxxxxxx>


To
wdsci-l@xxxxxxxxxxxx (wdsci-l)
cc

Subject
Re: [WDSCI-L] RSE performance against very large source files






I believe that I've entered the Twilight Zone.

The defrag made no noticeable difference Wednesday. However, something
has changed between Wednesday and today, because I'm suddenly getting
member filter response times of under 2 seconds! I suspect that 'they'
did something to the iSeries, since I heard indirectly that there were
people having performance problems with some kind of file transfer
application that they were testing on Wednesday. Outline builds seem to
be slightly snappier today, too, although logins to connections on that
machine are still as slow as ever (30 seconds to a minute where our
production partition only takes 5 seconds or so). I have to say that I'm
suspicious about whether this improvement will last, but for now I'm happy
with it.

Dave Shaw
Mohawk Industries

----- Original Message -----
From: "Dave Shaw" <daveshaw@xxxxxxxxxxxxx>
To: "wdsci-l" <wdsci-l@xxxxxxxxxxxx>
Sent: Tuesday, February 05, 2008 2:10 PM
Subject: Re: [WDSCI-L] RSE performance against very large source files

Don,

Thanks for taking an interest in this.

For reference, the PC is a Dell Latitude D620 laptop, 2 GHz Intel Core 2

Duo processor, 1 GB memory, 74 GB 7200 RPM hard drive (20 GB used), Win XP
Pro SP2, pretty current on patches (they test MS patches here before
distributing them, so I may be a week or 2 behind). WDSCi is 7.0.0.4, and
Installation Manager says I'm current.

The iSeries is a model 890 with processor feature 7424, 2.5 GB memory,

and 6.1 TB of disk, 86% used (development partition - it goes up and down
a lot - it's up today). OS is V5R4. I'm not authorized to DSPPTF so I
can't tell you cume level, but Verify Connection says that it's current on
WDSC PTFs (I make sure they keep up with that).

My workspace is on my local drive, c:\wdscwb.

The virus scanner is McAfee Enterprise Edition, and I have no access to

any of the settings for it so I don't know how they have it set. Spot
checks in Task Manager don't show it consuming huge amounts of CPU.

I haven't defragged in a while, and it does say that it's due again.

I'll try that tonight, but I'm not optimistic about it making a
difference, since there's virtually no disk activity on the PC while I'm
waiting until the last 10 or 15 seconds.

The filter string is CAMSSRC/QDDSSRC(PRF*) MBRTYPE(*). For what it's

worth, I just tried an F17 in PDM and entered PRF* for the member filter
there, and got my list of 13 members in about a second. I don't often
subset by member name, so I was surprised (and impressed!) at the speed of
that. It seems to me that PDM has to be using a pre-built, indexed member
list somewhere to achieve that kind of performance.

I tried clearing the cache in WDSCi and restarting. Expanding the

filter after doing that today produced nearly identical results to
yesterday: pop up after 2 minutes saying that the server isn't responding
and do I want to cancel my request, and another 1.5 minutes after clicking
No until I got back my list of 13 members. I have another workspace
(created from scratch, not a backup) that I don't use much, c:\wdscwb1, so
I tried switching to it, clearing its cache, restarting, and then creating
the filter in it. It took almost 4 minutes to come back; I guess the
iSeries didn't cache anything on its end.

To my uneducated eye, it appears that the cause of the wait is on the

iSeries, not the PC, but I could be wrong, of course. I'll have to see if
I can borrow the old clunker laptop that I used to use (750 MHz Pentium
III, 512 MB, 4200 RPM drive) and compare times.

I'm willing to play guinea pig for tracking this thing down with you, if

you're willing to put up with me.

Thanks again!

Dave Shaw
Mohawk Industries

----- Original Message -----
From: "Don Yantzi" <yantzi@xxxxxxxxxx>
To: "Websphere Development Studio Client for iSeries"

<wdsci-l@xxxxxxxxxxxx>

Sent: Tuesday, February 05, 2008 12:40 PM
Subject: Re: [WDSCI-L] RSE performance against very large source files

Hi Dave and others,

I'll start with some general performance tips, a quick summary of what
we've done so far and what we are planning to do. Then I'll finish off
with some specific ideas on your problem Dave.

General Performance Tips:

- Do not put your workspace on a network drive. Always keep it on a

local

hard drive. WDSC / RDi reads and writes lots of files while it is

running.

Putting your workspace on a shared drive will slow it down drastically.

- Periodically de-fragment your hard drive (for the same reason as #1).

- I have seen some virus scanners that scan every file read / written

to

the hard drive (at least for "untrusted applications"). This can have a

serious impact on performance as well. I'm not suggesting you turn off
your virus scanner, but it may be something you want to investigate and

see if there is anything that can be configured to improve it.

Diagnosing

if this is the case can be tricky. The one way we were able to

determine

this before was to setup WDSC to download a whole pile of smaller files

to

the local hard drive and then open Windows task manager, sort by the

CPU

column by descending then watch for processes that spike up to the top

and

disappear. Not an exact science, but a starting point. For anyone who
finds out this is a problem please let me know. I'll like some more
information on this one.


Changes so far:

- In 7.0.0.2 we changed the algorithm used for retrieving member lists
which should improve performance for member lists by at least a factor

of

10 compared to 7.0.0.1. Especially for long member lists.

- In RDi 7.1 we changed some of the caching algorithms to improve

caching

performance when a large list had been cached. Prior to this if a large

list (> 10,000 objects or members) got cached it would subsequently

affect

performance.

- Over the WDSC 7.0 and RDi 7.1 releases we did memory and performance

profiling (and made some fixes) to make things run faster with less
memory.


Performance is an ongoing work item for us, but we do need help in
identifying and fixing specific problems that occur in the real world.
It's difficult for us to take a posting that describes a general
performance problem and be able to map that back to a fix in the code.
Both of the above 7.0.0.2 and 7.1 fixes resulted from PMRs (which

turned

into APARs) where the WDSC user reporting the problem worked closely

with

us to help identify the exact problem and fix it. I've read the

separate

thread about the difficulties in opening PMRs but unfortunately don't

have

a fix for that :(

I've asked Roshane Silva from our team to take a deep dive into the
performance issues and to a) open defects for problems we need to fix

and

b) publish some performance tuning / best practices for WDSC / RDi.

He's

going to start by scanning the mailing list archive for leads. Feel

free

to email him directly if you have some suggestions

(rhsilva@xxxxxxxxxx).

And now over to Dave's problem:

There is definitely something going wrong if takes 3 1/2 minutes to

return

a list of 13 members. A couple things I can specifically think of:

1. You may have expanded the QDDSSRC file at one point in time and the
entire list of 19,892 members got added to the cache and that is not
affecting performance (see my note above about the problem and fixes we

made to caching in RDi 7.1). The workaround for this is to clear your
cache (via the Remote Systems > iSeries >Cache preferences page) and

then

immediately shutdown and restart WDSC (the clear cache preference

clears

the disk cache but not the in-memory cache, if you don't shutdown and
restart then you may end up writing the memory cache back to disk. We

have

an open requirement to fix this so clear cache clears both disk and
memory).

2. What are the library, file, member and member type fields for the
filter (right click on the filter and select Change). RSE filters allow

you to enter a generic name for the library, file and member fields but

the i5/OS API we call (yes it's QUSLMBR) only allows a generic member
name. So if there is a generic library or file name we end up having to

do

multiple calls to first resolve the library, then the files within the
library, then the members within each file. So the multi-generic

support

is powerful, but can lead to poor performance. For example; you don't

want

to have something like: * for the library name, then QDDSSRC and PRF*

for

the member name. This would first resolve all libraries on the system,
then call the member list api for each library. (I just opened a
requirement to add a warning when creating filters with multi-generic
fields).

Let me know if those work or not. If they don't work then we can take

it

offline to diagnose the problem (if you're interested). It will likely
require us sending you some updated code with extra logging to narrow

down

where the time is being spent.