E1 8.11 Bandwidth requirements

This would largely depend on your interactivity level and Service Pack. It uses a number of JS scripts for high interactivity in recent SP's.
 
Ok, you made me do it - I have attached a very simple and short performance analysis screenshot, which illustrates my point with some degree of precision. At least now, there are some actual numbers for the unbelievers (and I can't blame you, because I would not believe this myself, had I not known this from experience).

Again, this is not an official benchmark in any way and you cannot refer to it and/or use it for any planning of anything ever. But still...

If this does not scare you, I don't know what will.
 

Attachments

  • 104873-perf.jpg
    104873-perf.jpg
    195.8 KB · Views: 247
One more scary thing, which was not included on this screenshot (sorry) is the CPU utilization - for practically anything I touched, from the Menu to any of the APPL buttons, the CPU would go 100% for 5-10 seconds. - basically, where there are no peaks on this screenshot, there will be 100% CPU utilization on the client, which explains the gaps between the peaks.
 
Wow, that's obnoxious. Work with servers sends down a 1 MB packet? And I thought the fat client code was bloated....
 
Here is my view (I am now running 8.11 SP1 and 8.95).
The OneWorld web client is, indeed, becoming an industry joke as "thin client." It is the biggest "pig" imagineable, I agree with all of you...
I am so glad the airlines' and banks' websites i use hadn't adopted such thoughtless approach to "internet architechture," or I would be using a telephone!
wink.gif
But, please, agree that most of the customers' complaints against the web-client over the years, have ended up making the situation even worse, with every release!
The weak-minded "architects" and marketing geniuses in Denver don't realize that you can't have your cake and eat it, without imploding the product! They can't keep peddling the web-client by promising to "mimick" and "parrot" the fat architecture "features," which pushy customers ask for, while still "scrubbing" the old toolset forms with the generator to make them run on the Java server.
shocked.gif

Also, have you looked at the crap that is being "restored" from the fat client functionality these days, even though it is totally unfitting to the web-client approach as a thin, few trips to the database, architechture? We now have MBs of javascript being pushed with each page to the browser, attempting to make the browser "fatter" than the fat client! High interactivity!?
In 8.95 I even have TypeAhead (AutoFill) for god's sake, red "in your face errors", "scroll to end," validations and interactions on every grid cell, "opening application" animations...

Someone at OpenWorld was once shamelessly saying that the browser PC, for advanced users may have to be multi-processor and need more RAM than an enterprise server
ooo.gif


BTW, FYI, the original excuse for eliminating Windows client support in 8.11 was "power forms" -- this was going to free them up to develop "native" web functionality of the old applications, without the limitations of the existing toolset. Let's count how many of these native "web-only" Java-friendly apps all 8.11 customers are using today. I have seen only one, which we are not using -- P42101, replacing P4210, I remember that it worked great, especially on the PowerPoint platform
smile.gif
 
Currently, we are evaluating the possibility of upgrading from XE to 8.11. But now I'm having second thoughts, especially because “Functionality” concerns rather than “bandwidth”. Are there any HAPPY customers live on 8.11?
 
There are many happy customers using the JDEdwards Web clinet on all major releases of the product. Unfortunately you've been hearing only the negative and not the positive.

This forum is constructed to "help" prople who are having issues and is not really for people to brag about their success so of course by going through this forum you'll only hear the negative.

I've got lots of clients who are quite happy on the web client.

Colin
 
I agree with Colin. Actually, our end-users are relatively happy too with the UI (there is always the initial acceptance...)

Also, this thread looks at the issue from a specific technical perspective (architechture, bandwidth). And compares stuff to Citrix, which has been a superior and bandwidth-friendly UI technology, for many years. That's all.

So, in your case, if functionality is the main concern than the technological base, even my own "rant" had mostly "positive" elements for you! I was trying to say that they are putting so much end-user functionality that the features sometimes contradict the web-architecture and the toolsets.
I am sure they are doing it precisely so that people in your position make the switch! So, yes, there are users that are happy with 8.11 SP1 and 8.95!
 
Here is my configuration:

E1 8.9
8.94.N1
WebSphere 5.0.6
HTTP Server 2 with compression
JAS has InteractivityLevel=HIGH
Windows 2003 SP1 (for all JDE servers)
SQL 2000 SP3a
Database and Enterprise servers are 2 separate servers. This takes the BSFN load off the database server.

I've also attached a screen shot of the total bytes from the point after starting my browser. My default home page is not JDE, so the numbers include bringing up the JDE login screen, logging in, and starting submitted jobs (which does an auto find). So from nothing to seeing a list of submitted jobs. Total is only 237,000. I have compression turned on, so maybe that's the big difference. And my processor never hit higher than 44% during the entire process. My PC is a P4 3.2 GHz, with 512MB RAM. I wholey agree that the idea of "thin" is questionable. You need a pretty hefty PC to run a "thin" client. I did some testing once comparing different PCs and the biggest difference in speed (measured in time) was the processor. The faster the processor, the faster the screen would give control back to the user.

But I agree that your processer can hit 100%. Especially if you go to any app that displays a large grid, the processor will go to 100%. And this high cpu usage can last for quite a while if you are looking at a large number of rows too. In fact it can be very painful! The only way to help is to create a custom grid format with only the columns you need to see. This can speed things up by a factor of 4 or more. This is a problem with i.e., not JDE. The 100% cpu and long time displaying the data is due to i.e. rendering the grid. I know someone who tried using Netscape and the difference in speed was unbelievable! But Netscape didn't work for all apps. :-(

P.S. I loved the banking comment. Way too funny. But it made me think "I've gotta test out that theory." So I did the same thing. Logging into my web banking site and viewing a list of recent transactions (akin it submitted jobs) had a peak of 13% cpu and had 320,000 bytes received. Pretty comparible if you ask me. :) I guess it's back to telephone banking. LOL!

Andrew
 

Attachments

  • 104934-JDE - Login and Submitted Jobs.doc
    44.5 KB · Views: 157
Andrew,

Thanks, the more actual data, the better (otherwise the die-hard WEB supportes will believe me faking it ;-)

I was running this from a 1GHz-PIII client, hence the higher-than-yours CPU utilization (although it was not shown on the graph I posted, I only mentioned it).

And yes, the lower "bytes" value is likely due to compression. And, probably, the older Service Pack as well - WEB client is becoming hungrier with every release.

The problem is not exactly with the "rendering the grid", but with the way it had to be programmed in JDE to maintain its usability (aka: "High Interactivity"). If this grid were in plain HTML code and without a zillion of events, it would have taken a millisecond to render.

I just wanted to clarify, that these "bytes" are mostly Java scripts, not the actual data in the Grids. And most of the CPU time, probably, goes on parsing the scripts and attaching/validating Events to the GUI elements.
 
I wanted to test my bank's website, but I couldn't.
The site was down for 2 1/2 hours, during their weekly COBOL-to-JAVA generation, using their "native" eGenerator
smirk.gif
 
For shame....a PIII? This is thin client technology we're talking about here, you'll need at least a P4 or better. By the way, I do think it is silly to use JDE Web Client and "Thin Client" as if they were interchangeable, but in reality folks should just accept the minimum *recommended* requirements and deal. P4's have been around for what, four or five years now?


Response Time Benchmark: (customer fetching 200 rows, clearly showing the impact of processor speed)

Processor CPU Memory Response time (secs)
P3 1.1 261 22 seconds
P4 1.5 261 12 seconds
P4 1.7 261 8 seconds
P4 2.0 1GB 7 seconds
 
It surely needs a dual-core/HT-enabled P4 Extreme Edition (i.e.: Model 955) CPU, to work as intended... [sigh]
 
[ QUOTE ]

Does anyone remember his name? I am old and I am using that excuse. Jon, do you remember?


[/ QUOTE ]
Captain Internet was Paul Orsack (might be mispelled !)

Paul was in the Dallas office and developed the JDE Web client versions 1,2 and 3. I do not believe that anything he developed has any similarity with the 8.9x webclients. I would suggest we're at around version 8 or so with the current service pack levels. Paul left JDE in 1999 and development was moved from Dallas to Denver and placed under Foosballs team. At that point, they started to redevelop the web client and when Peoplesoft took over they redeveloped it again. Theres a LOT of redevelopment that took place - remember, Pauls product was primarily JRun based.

Why is it that whenever I make a sideline comment, it always generates the longest threads in the forum ! I guess I have a tendancy to hit on the soft-spots when it comes to technical issues.

All my comments were created from a functional user standpoint. If you want to get an even bigger thread going, I can talk about the technical standpoint - which by the way I have always supported. The technical architecture behind how jde converts code into its various forms has always been the right method - but the slaphazard way that JDE has treated performance has always left me with issues. The comments about "everyone has bandwidth" is very blinkered and shows that the issue is very little understood. The issue isn't just with Bandwidth - you can send unlimited gobs of bandwidth at JDE and it will still not perform anywhere close to a streaming technology like citrix - the issue is also latency and the number of turns that the application uses.

JDE Fat client is unbelievably chatty. If you search through these forums - you'll see posts that show how chatty the application is. Web isn't as bad - but its still very chatty since it has to wait for certain actions to occur between the server and the client before moving to the next event. Citrix was able to "skip" screens to ensure that latency didn't get in the way.

There ARE issues with the citrix client - but at least it delivered what it promised - which was a manageable high performing solution. I have yet to see a manageable high-performing web solution. Of course, I know it WILL come - but if the users and customers stop pressuring Jopsacle, then you'll never see that solution and instead it'll become worse and worse.

My bashing is over the strategy of dropping the win32 client. They did this to try and encourage performance development on the HTML client - but we haven't seen any benefit yet - as anyone can see we still have a badly performing webclient that needs us to increase bandwidth and hope our users don't complain too much.

I'm looking forward to seeing 8.96 - and I'm hoping theres some changes in the area of interactive performance. If not, however, then we'll just have to look for some alternatives to get the performance.
 
[ QUOTE ]


Does anyone remember his name? I am old and I am using that excuse. Jon, do you remember?

Richard Jackson

[/ QUOTE ]

Paul Orsack.

Unfortunately he had NOTHING to do with the web client beyond B7331, ie prior to when JDE decided to use Websphere. Therefore, all of "captain internets" work was pretty much a waste of time, space and money...
 
Back
Top