Thin Client Performance

mikebodette

Member
We've recently implemented JDE ERP 8.0. Our database server is an AS400 and our JDE web server is a Windows 2000 Advanced server. We have about 50 users that are purely thin client users. We have about 15 fat client users. We have a big performance issue with the thin client data retrieval. The web server is responding just fine but when requesting data through the thin client the speed is much, much slower than if requesting the same data through the fat client. The data retrieval speed is so bad on the thin client that timeouts are fairly common. Any ideas on how I can improve thin client performance?
 
Make sure the following parameter in the JAS.INI file:
[WEBGUI]
bandwidth=narrow

Have you change the data items OID and UID from data type lenght of 2 to 20. If not do it. it has to do with performance.

Is the jasdebug.log inactive? It should be.

Enable servlet caching through the IBM WEbspehre console or through serveletcache and dynacahe files on websphere\appserver\properties.

If your server has at least 2 GB of RAM set you Java heap size minimum and maximum to 512 mb.

Luck.
 
My [WEBGUI] entry was set to wide so I changed it to narrow. I'm curious how narrow could be better than wide. Thoughts?

The jasdebug.log is already inactive.

The server has 4 GB RAM and the Java heap size is set to 1024 for both maximum and minimum.

Where in the Websphere console would I find the servletcache and dyncache settings?

Where could I check the OID and UID settings?

I also recently changed the [ERP INTERACTIVITY] Interactivity Level to HIGH. I had it at MEDIUM before. I didn't see any change in performance by doing this.
 
Mike,

What SP level and one_off are you using. I had a similar problem with SP22_C which was resolved by applying SP22_i. The issue occured when the interactivity was set to anything other than LOW.

Try change the interactivty to LOW to see if this resolves the issue for you.


Andy
 
Remebre that you have to restsrt services so changes take effect.

For the OID and UID data items do the following:

1. In the generation machine.
1.1 Go to DD aplication.
1.2 Filter the OID and UID data items in the alias field.
1.3 Change the data item lenght from 2 to 20 for both data items.
1.4 Generate the F989998 and F989999 tables to take the change for the columns (before this make a bakckup for both tables, otherwise you will have to generate all over again.)
1.5 Log off OneWorld
Delete from the generation machine specs for you desirable
path code the DDICT, DDTEXT and GBLTBL files.
1.6 Log on One World so the files get created automatically.
1.7 Excute the R92TAM and R98CRTGL (After copying the files under B/ generated by the R92TAM batch)
1.8 Log off OneWorld and execute gen.bat to regenerate these two tables.
1.9 Run TAMftp.exe in the generaion machine to replicate the changes to the enterprise server.

To enable servelet chaing go to the IBM Websphere administrative console and expand until the Aplication Server, choose the Services tab --> WEb Container --> Edit Properties -->Servlet Caching tab, and check the "Enable Servlet Caching" Cahe Size 2000.

Also add the following in the System Properties panel of the Application Server:
Name: invocationCacheSize
Value: 50
Besides I send you an script that contains the indexes that you must have in the F989998 and F989999 tables.
 

Attachments

  • 67643-f98_jas.doc
    48.5 KB · Views: 216
We're running SP22_B1. I'll try the LOW interactivity setting and see what happens.
 
Well, the LOW setting has proven to make a difference. I'm not sure it's the whole answer but people are able to enter orders quite a bit faster. There are some things that are taken away when using this setting however. For example, when viewing more than 10 lines, the scroll bar on the right is no longer there and it has been replaced with the up and down arrows that display 10 lines at a time. Again, the data is retrieved faster than when set at the HIGH setting. One thing that is kind of strange now is the fact that we are seeing a lot of white screens now. There quick, mind you, but they are still annoying. Anything we can do about that?

We're planning on installing service pack 22_K1 at the end of the month so we'll see what happens then.
 
Mike,

I would agree that the LOW setting is a bit of an annoiance to the users, but it will get you over the hump. The white screens are the refreshes that occur with the LOW interactivity, this will go away once you are able to set the interactivity back to medium or high.


Glad that this worked for you.

Andy
 
The whte screens aren't exclusive to low interactivity. What happens, in broad terms, is that the frame of the page (top bar, colour scheme and the white page) are delivered from the web server. The infill of the grid etc. gets made up by the local PC in IE. If you watch in task manager you may well see the processor on the pC max out whilst the screen is white.

You get more with the low interactivity because you rebuild the grid more often- each set of records. You get more if you have more lines in the grid (or they tend to be more noticable).

Higher spec pc = less white screen - just what you want from a "thin" client eh?
 
Andy,

Where would I find this setting? We are currently in our CRP phase and there is a BIG difference between fat and thin clients. It takes over 20 minutes to do an inquiry in an AR screen. Does this setting only deal with Webshere?

Thanks
Stephanie
 
Stephanie,

The INTERACTIVITY section of the JAS.INI is at the very bottom, only if you are at SP22. These settings control how often the http server will intract with WebSphere, not with webshpere alone. An example of this would be if you are set to high interactivity then whenever you exit a field the HTTP server will interact with WebSphere to validate the entered data. On medium it interacts after you exit the row. Low interacts at the form completion (Click OK).

This it what the section looks like.


[ERPINTERACTIVITY]
#interactivity level. valid values are: LOW, MEDIUM, and HIGH
InteractivityLevel=HIGH
# whether multiple browsers fetch is enabled
MultipleBrowserEnabled=TRUE
# the maximum number of open browsers for each user
MaxOpenBrowsers=10
# the number of records fetched for each database fetch before getting a system warning
DBFetchLimitBeforeWarning=200


Hope this helps.

Andy
 
On your step 1.3 When you are refering to the data item length, are you refering to the Data Type changing from a 2(string) to a 20 (Variable String)?

Size is already set to 254.
 
Back
Top