8.19 / 9.0 Performance issues, tuning tricks

[cncjunior1]

[ QUOTE ]

So, evidently, this CAN be set by USER ID from 8.98 onwards !!!!! This is very important to note.

[ QUOTE ]

Set user profile accessibility mode to No by doing these steps:

Go to P0092 (Work With User / Role Profiles)
Do an open Find and Select the correct Userid
Set radio button for "Set Accessibility Mode" to NO
Click OK and Close


[/ QUOTE ]



[/ QUOTE ]

Jon,

I'm running 8.98.1.4 with all the latest Tools ESUs and I don't see where that setting makes any effect on the interactivity level anywhere. I'm assuming you are refering to the "Visually Impared" field which is linked to the ULFUTTIME1 field in F00921. No matter what I change it to it still keeps the user at a high interactivity setting. So unless I'm missing something in my setup I think the interactivity mode is still determined only by the JAS setting.

Nice latency stats by the way though.

 

[gregglarkin]

[ QUOTE ]

Nice latency stats by the way though.

[/ QUOTE ]

Be careful about asking Jon too much about his latency stats, other wise he'll try to send you a bill for $75,000.

 

[altquark]

CNCJr - no, I'm not sure they were referring to "visually impaired".

I couldn't test this on our 8.97 version - but I have a copy of 9.0.1 standalone running 8.98.2, and I see it under P0092 there - so either there is a planner ESU that updates P0092, or it comes out ONLY with 9.0.... (my quote in my previous post was directly from metalink)

Anyway, I'm attaching a screenshot of the new user setting.

Otherwise, you'll have to test this by setting the JAS Instance through the JAS.INI.

 

[altquark]

ok - here are a few more "tests".

Heres the synopsis. I used Demo Jr 9.0.1 Tools Release 8.98.2.0 running in VMWare. I took all the packet figures from the VMWare virtual interface.

I started OneWorld in DemoJr, then minimized the vmware virtual machine.

On the HOST machine (or, if you want, you can do this across the network) - I opened the browser and connected to http:\\{demojrvirtualmachine}:8888\jde\owhtml

I used a combination of browsers (Microsoft IE 6.0 and Firefox 3.5.5) and turned the interactivity between "HIGH" and "LOW".

My "script" was as follows :
1. Note down the packets sent/received
2. Login as Demo - when the menus appeared, note down the ending packets sent/received
3. Start P4210, Click Add, Enter M30 Branch, 4242 customer and create a 4 line sales order with items 2001, 2002, 2003, 2004 and click "OK" twice (there is a warning on two of the items). Note down the ending packets sent/received

I pre-loaded all of the images, JITI'd the apps etc by running through the script TWICE per browser/user type before actually running the above script and noting down the results. This is to get rid of "cached" information on first run.

Here are the results (attached as a spreadsheet). Now, my disclaimer is that this was a "quick 'n' nasty" test. These are NOT empirical results and is certainly not a true benchmark/stress test - but it gives a good idea of some of the differences.

What I DO find is that Firefox uses ONLY half the number of packets that Internet Explorer does. Not sure why. Secondly, there is definitely a big difference between a LOW interactivity user and a HIGH interactivity user - but the number of packets is actually GREATER. My guess here is that the number of TURNS is lower. The ratio between the Microsoft IE 6 high-interactive vs low interactive is about the same as the Firefox high-interactive vs low interactive, so the results are pretty darn close.

This would have to be put through a more in-depth benchmark before it could really be relied upon - but if you're looking into tuning across a WAN, it might be worthwhile looking at Firefox instead of Microsoft IE as your browser ! I have yet to test this against Safari....!


Fascinating stuff.

(By the way, the spreadsheet states "IE 8" - when it is actually IE 6.0. It's a typo in the spreadsheet. I haven't yet tested this with IE 8)

 

[KSI]

Jon,

The fire-sale on packets is explained here:
http://josephscott.org/archives/2009/08/xmlhttprequest-xhr-uses-multiple-packets-for-http-post/

KSI

 

[altquark]

Thankyou. Interesting article.

More real-world/empirical research is needed. But right now, it looks like simply switching from IE to Firefox saves half your packets ! Not sure if you get "twice the performance" - but its a start !

 

[cdawes]

Cool test Jon.

What were you actually using to measure the packets?

LOW Interactivity does send more data but sends it less often (fewer turns). This is the main benefit for low latency connections.

Now here's the next test (if you dare). Why not compare LOW Interactivity, HIGH Interactivity and Citrix (XenServer 5) and see what the results are.

Should make for a really interesting discussion.


Colin

 

[cncjunior1]

[ QUOTE ]

I couldn't test this on our 8.97 version - but I have a copy of 9.0.1 standalone running 8.98.2, and I see it under P0092 there - so either there is a planner ESU that updates P0092, or it comes out ONLY with 9.0.... (my quote in my previous post was directly from metalink)


[/ QUOTE ]

Jon,

I found the SAR for 8.12 that address this change. The SAR is 8751571 and is included in an ESU that has other changes to the P0092. The SAR states that the Accessibility Mode now goes to FUTTIME instead of FUTTIME1 in F00921. Below is the SAR description.

Description Of the Issue:
b7 The APP P0092 has been modified from 811 to show
an
additional option to choose between Visually Impaired
(Yes
/ No).
b7 This Flag was never used in Web Runtime codebase.
The existing data in the table has <blank>, 1 and 2 as
values.
b7 To avoid any possible bad data, we should to
use
a
different unused existing column FUTTIME instead of FUTTIME1
.
Desired Outcome:
1. Modify the User profile Applications to use FUTTIME
instead of FUTTIME1 for Accessibility Mode.
2. Below matrix should be used for displaying accessibility
Mode in the screen in update mode.
F00921 - FUTTIME - 'blank' - Accessibility Mode (No)
F00921 - FUTTIME - 1 - Accessibility Mode (Yes)
3. While creating a new User (Add Mode)
The App should show Accessibility Mode (No) as the default.
4. When the App Saves a new user Data, The Accessibility
Mode Yes should be saved in F00921.FUTTIME as '1' and
No
as
''.

 

[altquark]

[ QUOTE ]

LOW Interactivity does send more data but sends it less often (fewer turns). This is the main benefit for low latency connections.


[/ QUOTE ]

Right. I agree - more data is sent (more packets) but less turns.

To be honest - none of these tests are actually much good. I just wanted to demonstrate there was a difference - and there IS a difference between them. What is REALLY needed is a full-blown analysis between the different interactivity types and, yes, Citrix - and there are different ways to manage citrix too (reducing colors, seamless etc etc). I did a performance benchmark many moons ago - pre Xe - at JDE between HTML, Java Client (the old java client that went away before Xe came out) and Citrix - and those charts have been in use for eons. But JDE needs to update charts like those. The problem is they don't have the ability to test anything anymore - and it seems they just don't care either. God knows how they succeed in sales calls when these issues are brought up !

Once my lab is fully built (I have 32 processors and 96 Gig of memory with 48 port Gigabit ready to go - but I don't have the cooling yet !!!), I'll be putting up a few more benchmarks - including, yes, Citrix XenServer 5 - and I'll be comparing some high-watermark tests as well including differences between OAS and WAS, Linux and Windows....64bit and 32bit....

 

[tonycoval]

Since I am knee deep in low interactivity SARs, I can speak on a bit of this, as well as Firefox.

Low interactivity affects your results because it removes many javascript components of the application. So while it is loading more actual static pages, it is not doing multiple requests per page to load external javascripts. The primary example would be those headerless popup windows like in benefits enrollment "are you sure you want to exit and lose your changes" as well as some of the more dynamic java components, etc.

Now one of the primary difference of Firefox performance is that FF only will load an external referenced javascript once when it is referenced multiple times in an application page. IE will request it once for every time it is referenced ! FF also handles inline scripting and CSS better but I cannot remember the exact details on that.
Of course we need to make sure that we remember that IE out of the box only is using 2 concurrent connections out of the box (until you apply the prescribed registry hack) while FF is 8 concurrent connections out of the box.
If anybody is reading and on current IE right now, and haven't increased concurrent connections, DO IT NOW!

 

[tonycoval]

Oh, and yes, low interactivity IS for visually impaired - the app changes that eliminate much .JS is in order for the JAWS application for blind and VI can properly read and navigate the application.