P4210 Performance

[IMOK2A]

Havin' a heck of a time (as most people) with P4210 performance. Yes, I've made quite a few mods but none that really make the app any slower than the Pristine version of the program. Running on the largest (state-of-art Terminal Servers) and while monitoring them it doesn't appear that the boxes are even straining (P4210 doesn't seem to be taking up much memory/processor time). Enterprise Server = AS/400. EntpriseOne version = 8.10 (with just about every ESU applied).

I know there are several "tips" on how to improve performance of P4210 but, I'm not sure where I should start. Any ideas/tips/questions?

Any help would be greatly appreciated.

Thanks,
K2

 

[Larry_Jones]

Where are the BSFNs mapped to?

 

[IMOK2A]

All run locally (on the "super fast" terminal servers).

 

[Larry_Jones]

Do you make extensice use of Advanced Pricing? We don't but from what I've read here some Advanced Pricing setups can bring the biggest box to its knees . . .

Also assuming that basic DB and network performance is adequate.

 

[keikoo]

hi there,

could you be more speific on where you hit the problem? Says, after you click 'OK' to save the order? Or when you do 'row exit'...

 

[IMOK2A]

Thanks for everyone's input. The Advanced Pricing is darned near turned off as pricing is done by a custom pricing application we developed. So, that doesn't seem to be an issue. What I find slow is basically, two events: 1) Row Exit/Changed - Asych and, 2) Grid Row is Entered. There are two reasons for this: 1) JDE/PeopleSoft/Oracle has a large amount of code in both these events and, 2) We added quite a bit of code to these events ourselves (table I/Os, etc.) However, I ripped out our code and tested again. Our code does slow the application down a bit but, not tremendously. Just wondering if there was some "trick" or "tips" to help speed things up because I know we're gonna take a hit when 10 - 15 Sales Reps starting hitting the system at the same time.

 

[BOster]

Have you looked for blocking (specifically F4211) on the DB server? That is the problem we have been fighting.

 

[IMOK2A]

Blocking? I don't think I'm familiar with that? Could you elaborate?

Thanks,
K2

 

[WhippingBoy]

How about your network? A slow network will result in what you're seeing.

 

[IMOK2A]

Network is good (although, you're right. It was initially a problem because it wasn't big enough). Now, it's not an issue (network admin tuned it while we tested the speed of P4210 to get it working as fast as possible). The app does seem to be running ok now. But, I'd still like to be able to do what I can now before implementation (in a month). Ya know, any tips people have had that could speed things up (i.e., recreate indexes or logicals on the 400, etc.).

Thanks,
K2

 

[cscdans]

Hi,
to help you I have got some questions, too:
Is transportation turned on, it can take a lot of time. There has been a bug where all detail records in F4211 has been updated.
What Version/PO settings of P4210 are you using?
Do you use Memory cache or workfile?
Did you do testing only with one or more instances of P4210 at the same time?
Is your Database/AS400 optimized, what kind of machine is it, how many DB-connections are opened?
Are any Tables cached?
Do you use kits or anything else, that writes in to the attatchment table F00165?

What is the technical spec of your terminal server?

What we found out: Advanced pricing reduces performance to 60%. We mapped the BSFN to the clients, but the CPU-power of the server is very important, too. The FS4211-BSFNs needs very much processor performance on the client!

Regards,
Carsten

 

[HolderAndrew]

Hi,

I have worked on SOE performance issues from B7331 to XE. In my experience the worst culprit is always advanced pricing but the surefire way to find out is to put logging on and analyse where all the processing is being done.

After doing this enter the same order on pristine code (if possible), again with logging on. Then compare! If same problem on pristine then at least you know it has nothing to do with your mods.

Another useful tool is to run the DB monitor and ensure that all required indexes are ok.

There are many reasons for slow performance but if you know where the processing is being done then I think this gives you the best direction of where to focus your energy.

Hope this helps.

Andrew Holder

 

[IMOK2A]

Thanks again for all of your input. I'll try and answer some questions here:

Is transportation turned on? No.

What Version/PO settings of P4210 are you using? Not sure what you mean here? We're using the standard PO template with a tap added at the end that we use for custom code.

Do you use Memory cache or workfile? Cache.

Did you do testing only with one or more instances of P4210 at the same time? Many instances.

Is your Database/AS400 optimized, what kind of machine is it, how many DB-connections are opened? Not sure about this. I'll have to find out.

Are any Tables cached? Don't know.

Do you use kits or anything else, that writes in to the attatchment table F00165? Nope. Straight up SOE with no kits, no advanced pricing, no transportation, etc.

What is the technical spec of your terminal server? I'll have to check. However, I do know it's the latest from Gateway and, the network people have been monitoring the processor and RAM. We're not taxing the TS at all!

I've tested both Pristine and our custom version of SOE. Our is just a touch slower - natrually - because of our mods. They both run pretty good so far (I've been tuning our code to make it more effecient). So, it's acceptable. I'm just concerned because in years past a major issue during go-live has always been SOE performance. So, I was just trying to get it as fast as possible before go-live.

Thanks again for everyone's input!

K2

 

[cscdans]

Hello,
I have just more Questions: Did you check in P99410 which modules are turned on/off? - Trun off all modules you do not need.

During your tests: What is the usage of CPU-Power on the AS400?

Regards,
Carsten

 

[IMOK2A]

Thanks for the reply!

Um, It looks like all the modules we don't use are turned "off" in P99410. As far as 400 CPU usage goes we're barely taxing the system.

One other thing I did notice (with both our modified version of P4210 and the pristine version - 8.10) was that the screen kind of "flickers" after you click on the OK button. It seems like as the ER processes the screen/filter fields flicker. Is there some setting on the Terminal Server that could be causing this?

Thanks,
K2