I got someone new at Oralce Help desk and she seems to think it has something to do with the fact that all our users are coming in over the WAN. Here is her response:
<font color="blue"> </font> Here is some information that I have for using web clients over a WAN environment...
TaskExplorer in Low Bandwidth /High Latency Network issues
1) Excessive Round Trips
Task Explorer when rendering the menuing tree makes a lot of Round-Trips to Web Server.
e.g. : in Staging package Internet Explorer makes 87 round trips to WebServer to render the initial menu
2) Voluminous Data being transferred
Task Explorer Rendering sends a lot of HTML data for the browser to render
e.g.: in initial rendering 124,000 bytes are sent , in subsequent rendering of child menus ~50,000 bytes are sent over the wire
1) Configuration Fix:
a) HTTP Caching : We have configured IBM HTTP Apache WebServer to set Expires header on resources it serves - in particular images
This would ensure that a HTTP Compliant Browser would not make superfluous roundtrips to retrieve the same image 50 times
With this setting Mozilla and FireFox make only 2 round trips down from 70+ to render the initial page
b) HTTP2 Data Compression: We have configured IBM HTTP2 Apache WebServer to compress HTML
with this setting the amount of Data compresses from average 50,000 bytes down to average 4,500 bytes
if we lived in a perfect world these two settings would result in low roundtrips and less data being transferred
however Internet Explorer has a bug which ignores the Cache Expires HTTP Header in inner HTML and still makes 70+ round trips
2) Code Fix
http://support.microsoft.com/default.aspx?scid=kb;en-us;319546
This is the bug in Internet Explorer which exhibits itself when we run innerHTML
This fix reduces the round trips to 24 down from 87 ,
this is the best we can do with InternetExplorer as it makes a new Connection for each unique resource
FireFox keeps the connection open and makes multiple HTTP Gets in the same connection
How Customer X got around the problem
Customer X turned on HTTP 2.0 compression which helped a great deal with general response time and screen rendering. However, they had an additional problem with their overseas sites when rendering the task views in the HTML client. This was caused by a 0 byte .GIF file which is part of the rendered task view (menu). There are dozens of these on a page and even though they are effectively empty, the IE browser had to go back to the web server every time one was called (because the local copy was 0 bytes) which resulted in a long delay due to network latency. To fix this, as well as to reduce the overall impact of other static HTML content, Customer X put in a piece of network equipment at their overseas sites that cached this type of content locally so the round-trips were on the local LAN and not over the WAN. This resolved the screen rendering issue.
Workaround for IE Bug
"To workaround the Internet Explorer bug as Microsoft says:
Create a brief time-delay so that Internet Explorer has enough time to verify whether the image is in the cache, and then call the innerHTML property."
to achievethis workaround: set this JVM property in the WebSphere's Generic JVM properties
-Dcom.peoplesoft.e1menu.ie.timeout="10" (or any other number)
this is delay in millisecs before E1 Menus will load the inner HTML
<font color="black"> </font>
Anyone have any thoughts on this?
