E1 8.X Application Performance with AS400 Enterprise Server

Hi,

I wanted to take a pole out there from some real world customers to get some feed back on overall application performance with an E1 8.X and an AS400 enterprise server.

I am trying to figure out if our company is in the norm or if we can improve performance by figuring out what is slowing our system down.

I know there are a lot of considerations out there to take into account but I wanted to get an over all feel.

We have an AS400 Model 820, V5R2 with 2 CPU/2350CPW and 19.5 gig of ram (allowing 2.5 gig for E1 users) and 948 gig over 57 disk drives.

Our performance on citrix and fat clients appear to be the same but I will stick to giving specs for a production built fat client with full datadict and global tables on it, just to rule out citrix and any antivirus or additional software running on our metaframes. My personal thought is I cant get it to run any faster on citrix then it will on a fat client and I think those are slow anyways.

We had JDE 8.1 and have recently upgraded to E1 8.10, 8.93L1. I have only seen minimal performance change but like I said I want to see what the norm is out there.

On a fat client machine I double click on the psft icon
icon and its a second or less for the splash screen to come up. After I input my password, environment and *All for role, it takes 10 to 15 seconds for the task view explorer to come up. Was about the same in JDE8.1 and E18.10.

When droping down menu options in task view it used to take less then a second on JDE81. but now takes 1 to 2 seconds on E18.10.

Full pacakge builds take the same amount of time 7 hours for the client and 7 hours for the server.

Another slowness we see is when we jump between screens. When opening and closing applications it can sometimes take 2 to 5 seconds for the screen to repaint. It does not happen all the time but on a good number of screens. I logged some of it one time back on the JDE8.1 system and figured out it was the user overrides. The log appeared to be cleaning them up so the screen wouldnt refresh until it was done.

When you remove all the user overries or *public overrides in the grids for the screens, they would open and close in less then a second. Again we dont have many user overrides maybe 1 to 3 on screens. Most are usually just the *public and everyone uses those. All of those have just the default sorting (on index) nothing special so im not sure if its normal to close a screen and wait a few seconds for it to repaint while it cleans up.

Thanks for anyone elses input.
-jason

There are many parts to consider between your mouse-click and the final result display: how much horse power does your PC have, what are network speeds and loads at the time, where does your application server reside and what is it (JAS or …), and finally how optimized is your iSeries database.

For self-help on the last piece, you should run your jobs with debug on so query optimizer writes optimization messages to the joblog. You could collect DBMON data and on the jobs servicing your requests and import that collection into iSeries Navigator SQL Performance Monitors for analysis.

When you use WRKACTJOB, do you see a lot of temporary index builds taking place (IDX in the Function column)? This would suggest temporary index builds are taking place and you’ll need to optimize his database by building some permanent indexes.

All My Best,
Jen

Hello Jen;
Just a Quick note; How can I build Permanent Idexes for some Tables, b=since what you described below happaened in Our Organaization, another Question Why the system Creates a Temp Index and not use the Existing Ones?
Hope to hear U Soon

Ibrahim -

Our August newsletter leads with the article "Case of Overlooked index". It matches this discussion topic perfectly.

Also, here is Kent Milligan's response on a similar question:
http://search400.techtarget.com/ateQuestionNResponse/0,289625,sid3_gci111626
1_tax285216,00.html (or http://tinyurl.com/bg5us )

Bottom line is that there is no guarantee that index you build will be used.

Since query optimizer considers myriad of factors when making optimization decisions (cpu utilization on the system, memory pool allocation, MAXACT level on the subsystem, availability of statistics ...) you should always try to optimize your queries in the environment they will run. And yes, that means production, when circumstances permit it.

Using STRDBG, STRDBMON, iNav SQL Performance Monitors you can tell if it was used or not.

Query optimization is an iterative process and that is where our tools come in.

One more thing. Since (it seems by your 4am post) you're not in US timezone, Mike Cain's webcast "Indexing Strategies for DB2 UDB on iSeries" will be available after 9/15 for download online. I suspect you'd have to get up in the middle of the night to join real-time

All My Best,
Jen

When an SQL statement is executed, the system determines an access plan to use for the query. When developing this access plan, the system looks at a set number of indices before it decides to create a temporary one. Many tables in JDE already have way too many indices created over them and the system does not look at every one.

In order to create a permanent index, first you have to determine what it should look like. You can use tools like the database monitor in Operations Navigator to determine this. Then use the CREATE INDEX in SQL to create the index.

Silly mom of mine....you didn't give them the link to the newsletter!

http://www.centerfieldtechnology.com/publications/archive/August%202005%20Newsletter.pdf

There...see you this weekend!

Love,
Aspen

E1/Xe, Enterprise Server iSeries running DB2, Web Client, JAS/Websphere 4 on Intel/Windows