Improving JAS performance

Does anyone have any good documentation on how the performance of the HTML web client can be improved? We have a remote site that uses the web client to access the servers via VPN. However, the users are saying that it's slow. We're using Websphere, MS-SQL 2000, ERP8.1, on a Windows 2000 platform. Any help would be greatly appreciated.

Have you changed your tnsnames.sql file to add SelectMethod=cursor;sendStringParametersAsUnicode=false to the end of each entry?

Example:

Business Data - Training=(jdbc:sqlserver://servername:1433;databasename=JDE_Training;SelectMethod=cursor;sendStringParametersAsUnicode=false)

One question would be, are your local users complaining too? If so, then pursue the WAS/IIS Tweaks. If not, then you're more than likely up against WAN latency, in which HTML compression may help you. It cut our response time to Mexico from an average of up to 4 seconds, to an average of a second or less. Mind you, it doesn't speed up transaction processing time, but will speed up the data/screen transmission speeds quite a bit. Depending on what you want to do, you can get a solution costing a few hundred dollars, to tens of thousands. Since they all use pretty much the same compression algorithms it's how much do you want to spend for the bells and whistles that are typically included. Here's a few vendors you can take a look at if not familiar with web compression: xcache.com, activnetworks.com, redlinenetworks.com, ehyperspace.com, packeteer.com. Then, of course you can go as basic as simply turning on IIS compression if you're running IIS. Good Luck!

From what I have read, hardware HTML compression is better than software compression(third party applications) and is more reliable. Has anyone got any experience in this? For the # of users a hardware solution is not cost effective. I have heard that Redline Networks has a nice product. Also, what steps are needed to turn on IIS compression?

The bigest bang I've seen so far with hardware versus software compression has been the offloading of the overhead associated with the compression process, especially if using SSL. Also, some of the compression hardware devices can do other things, such as compressing other types of traffic, such as SMTP, or FTP, can do caching, reporting, etc. Again, the more you're willing to pay, the more bells and whistles you can get.

If you just want straight compression, you can activate it in IIS 5, or 6. There's an article on EggHeadCafe which outlines how to activate it on IIS 5 (http://www.eggheadcafe.com/articles/20020716.asp). As for IIS 6, try http://www.microsoft.com/windowsserver2003/iis/compression/default.mspx. I didn't dig deeper to find the actual article(s) on how to activate it with IIS 6, but that should give you a good starting point.

Ultimately, we opted for a software solution, because we could afford the slight overhead it imposed on the web servers and we didn't want to have to deal with another obsolete appliance in a few years and another potential point of failure. Not to mention the software solutions cost much less.

Recently, using TestComplete, ERP 8.0, SP23, Window 2003 Server, IIS 6.0 and Windows 2000 workstation on the workstations, we compared a GUI intensive fixed asset scenario with a 400mhz (WBPERF3) workstation against a 2.4ghz (HQJDS06) web server this had a run time of 18 minutes.

We ran the same test using a 2ghz workstation (WBPERF4) and the time dropped to just over 9 minutes.

We repeated the test again using the 2ghz (WBPERF3) and the 400mhz workstation against a 3.6ghz (WBPERF4) JAS server and the numbers remained virutally identical.

About a year ago we did some testing using SP22 against the WAN. It demonstrated that the performance of the users workstation was almost as important as the speed of the WAN in determining performance.

The moral -- get data entry users very fast workstations. So much for the concept of the thin client.....

The other document...