E1 8.11 Bandwidth requirements

Roy Wilsker

Member
We are implementing E1 8.11 SP1 (8.95 Tools) on the iSeries. We are looking for detailed information on bandwidth requirements for the web clients. According to Oracle, their last documented information is from four years ago. Does anyone know of more recent information?

Thanks for your help.
 
I guess, it's because it wouldn't look very good. Here are my approximate calculations:

An average single WEB page is about 1 MB in size (counting all Java scripts it loads).

So, if you have 100 users, opening 10 pages a minute each, it will use approx 17 MB/s, or about 200 Mb/s in network terms - note the "MB" vs. "Mb" difference.

Hence, a single 100 Mb Ethernet card will not be enough and a single 1 Gb Ethernet card will be ~20% utilized for the sample numbers above. This is for the WEB traffic alone.

Of course, this is just a conjecture, but it's probably close enough...
 
Adding to Alex's comments - if you send all of that traffic directly to the browsers, then you will need to account for that traffic in your enterprise. Here's a different school of thought for managing that network traffic. This is an excerpt from a soon to be released article that I wrote....

"Dear Mr. Solution Explorer Guy,

I have another Citrix question for you. We are on EnterpriseOne XE and are looking to upgrade to 8.11. We have ten Citrix servers and gobs of licenses. 8.11 is Web based. Do we need to write off our investment in Citrix, or does it still have a place in our business?

- Citrix guy in Cincinnati again

Hey Cincinnati!

Great question! You have some options to consider. Yes, EnterpriseOne 8.11 and above are Web based applications. Likewise, Fusion will be Web based, as seems to be the trend these days. Just about everyone has a browser installed on their PC. So one school of thought is, let’s junk the Citrix servers. One factor that doesn’t get talked about much is the Big-J factor. A sophisticated Web-based ERP application, be it 8.11, Fusion, MySAP or any other flavor, relies heavily on Java. Most Java applets are very memory intensive. They can also be quite large. If your users are spread around geographically, connecting to your servers over a VPN (Virtual Private Network), downloading the Java applets could be a very slow process. Another factor to consider is network bandwidth. In the Citrix model, most of the network traffic occurred between the Citrix server and the Enterprise server(s). Those were generally on a LAN, often located in the same server room. The only traffic going out to the user was screen refreshes using the ICA protocol. That network traffic was in the 10K range; pretty minimal stuff. In a browser based world, you have data and Java applets going out to the local browser on your desktop. If you throw in a smaller network pipe that your remote users have at their disposal, you have a recipe for a big performance hit. A final factor to look at is security settings on the browser. If you take a look at Internet Explorer, you’ll see that there are all kinds of settings to tweak for security. There are lots of potential security holes here to give your corporate auditors a headache.

So what’s a self-respecting geek supposed to do? I would recommend keeping your Citrix servers around, but give them a new job. Some of them can be recycled into Webservers. Keep the rest as Citrix servers, use them to host the 8.11 client. Publish Internet Explorer as a published application, but crank down the security so that users can only access EnterpriseOne. In this configuration, you will have tight control over the security settings of the browser. You can ensure that the latest virus protection is applied and active. Java apps will reside on a corporate server, not a desktop or laptop. Those servers will be on a LAN near the enterprise servers, so performance will be excellent. Finally, you can maintain the tiny network footprint of the Citrix ICA protocol. (OK, I’m a big fan of Citrix. There, I admitted it. We have a club and everything. We’re thinking of printing up T-shirts.)"

This is an excerpt from a larger article under my pen-name of Mr. Solution Explorer Guy that will be published in April. I hope that helps you put the bandwidth investigation in the right context. Good luck, let us know how it works out.

Gregg Larkin
JDE System Administrator (CNC) / North America
Praxair, Inc.
 
Richard,

No. No actual network measurements, but I did look at the page sizes and it certainly feels right, based on experience.

I'm sure someone out there would have measured it - if anyone has any measurements, please, let us know.
 
The actual answer, is "it depends"

Alex is right - certain webpages in EnterpriseOne provide approximately 1Mb of data - thats a lot, but of course much of it becomes cached, so not all of it goes over the network.

Secondly, theres a lot of crud that gets sent down - stuff you might want not to have to push over the network by creating a thinner HTML regen. If you DON'T want the major bandwidth being sucked up, and if you're fine with ensuring lower functionality - then go lite !

In comparison, the web client is a LOT more bulky than Citrix, which can work on connections as low as 4KB/s (a modem for example). I can run OneWorld through my PDA in Citrix over my sprint PCS connection. The same is not easily achieved in the web.

There are some users that will be predominantly higher useage than others - I've always stated that power-users shouldn't be given a browser to work with day in and day out - but Popsacle ignored my whines, and forced the power users to be java-web client with 8.11. Not nice.

I remember being told "get with the program, Jon, Web is the future" when talking about the OW client about 5 years ago. I remember telling them "well, I'll subscribe to it when it has the same functionality and performance as running the Win32 client through Citrix". Sure, its better - but its about 10 times slower and requires about 10 times the hardware in comparison to Win32 on Citrix.

As a sideline - My question has always been "why ?" when it came to the amount of effort JDE/PSFT/ORCL put into the web client. The cost of developing the web client at latest estimates around 4 to 5 times the cost to write OneWorld - its also taken just as long !


I've always been viewed at as some sort of dinosaur akin to people holding onto Greenscreens when it came to web clients. Not to say I can't implement them - I helped get the first JDE users live on Web, and still help people today. But web clients replacing windows clients are not the same situation as greenscreens being replaced by windows. Windows clients gave MORE functionality to the user - something we sold heavily at JDE - and Web clients take AWAY functionality - how can you sell that crap ?

The future is still web. But theres still a surprising number of new customers moving to 8.10 instead of 8.11 to ensure they can use both. If you have the chance, I'd recommend 8.10 over 8.11 for the technical reasons.

Of course, you could always publish your browser through citrix....(!)
 
I totally agree - on all points.

There's also HTML compression (both software and hardware), which can further reduce the traffic by maybe around 3 times.

But there's also one thing I have failed to take into account - most JDE pages have multiple frames, each of which are including numerous .JS scripts, so "a single page size" can sometimes go up to 2-3 MB.

And I am not at all certain about any caching - yes, IE does it, but the pages may have "NOCACHE" tags, forcing IE not to cache anything.

Again, I have not looked into this issue deep enough, I admit, but overall, the entire WEB thing is really ridiculous because of it's security, performance and functionality drawbacks.

If you remember, originally JDE was developed in 3 (!!!) different flavours, not two like now - Fat, HTML and Java.

Java part was then abandoned at some stage, which of course raised my hopes, that the HTML would be abandoned too, but apparently the marketing people prevailed once again...
 
I think a reasonable person must consider the fact that the old technology is at an impasse? I mean, when the Everest project was kicked off, were they really thinking the fat client was going to be around in another 10 or 15 years? Perhaps they were, I don't know. The technology behind the fat client is dated, but I'm not calling anyone a dinosaur.

In my experience with Citrix, and we use it extensively, it just isn't the best experience for the end user. There needs to be something else, better than the current web client with the benefits of a protocol like ICA. Look at what happens when a user in a remote office is setup with Citrix for all of their applications, then they print from the application through a server either next to the Citrix box or back at their home base. Without packet shaping or compression of some sort, you can start to bog down some really expensive connections. The end result is you have performance issues there as well. Printer drivers can make all the difference in the world, but the technology is just flaky. That part of Citrix always has been.

Look at what they are doing with 8.12 apps and 8.96 Tools - XML specs makes TAM obsolete. OK, it isn't released yet, but they promise it will be there any day now. I say it is about time - perhaps we'll have less people managing the same application some day, maybe even before we are forced off of the JDE EnterpriseOne product landscape. No more "build the package then convert the files you just pulled from the database into another set of tables in the database."

The development client is also in need of a facelift and overhaul. They started working on the Eclipse stuff, perhaps even before the PeopleSoft aquisition (I don't know), and you really have to give them credit for embracing some technology related to open standards. That benefits everyone, including the employers who can start to pull in more developers who don't necessarily have their chops in JDE but can adapt with a familiar toolset.

I think the bottom line is you have to look at the, um, bottom line. It costs the software vendors less in resources if they can migrate to open standards and of course outsource their daily operations to the lowest bidder. The technology will get there and they have made great strides in the past couple of years, perhaps technology is just keeping them afloat, but if they are going to stay in business (Oracle and any other business software vendor, that is), they will have to keep steadily improving their products.
 
You may want to go to the webcast advisor from peoplesoft for your additional reference. They have presented something about saving money if you eliminate TS server farms and move all apps to the web to that effect sometime in June 2004 (not sure if this webcast is still available). There was a comparison made for citrix and web in terms of network performance. It’s basically saying that web has lots to offer than citrix for the enterprise….but after reading the comments from the gurus, I may need to reconsider my plans of going 100% web.
 
Well, Charles, it's yes and no: Open Standards is as much of a marketing hype as anything else I've seen.

Consider, that every time a new release of Java comes out, they need to re-test everything and likely re-develop parts of the foundation. Because otherwise, it just simply will not work anymore.

We have all seen this: each JDE JAS SP supports a point-release of everything. Move a half a service pack either way in any underlying software package and it doesn't work anymore.

This was not so ugly under Windows - there, you may need to make some very occasional changes to keep up with MS Service Packs, if at all.

After all, the leading-edge Microsoft Windows is basically still running the same Win32 platform, it was originally developed for (some 15 years ago?). The addons, like .NET, don't really count, because it's still basically the same VC++ or VB, which are compiled to call the same Win32 API's.

I am also highly suspicious about the XML specs. Consider, that the structure of the specs is still fundamentally the same and the Foundation will need all the same flags, but where it was a single byte, it will now be a 100-char string, wrapping up this byte's value.

Obviously, this will blow the size of TAM up at least 10-20-fold and make parsing a nightmare. Remember the wonderful new User Overwrites XML format, which didn't really improve anything?

Apparently, the new XML TAM will also be ZIP'ped, to save the space (or rather to hide the size growth), but this means, that every time an APPL needs that single byte, which I mentioned before, it will have to 1) Unzip the TAM, 2) read 100 chars of text (or likely even more), 3) parse it into parts to find that byte and 4) convert it's string value into the byte, it needed in the first place.

Plus, converting it into XML will not make it any eaasier to use or simplify it's structure in any way - this is too deep in the JDE foundation to change.

Consequently, I will expect the initial cut to be practically unusable - this is too big a change to counter all possible bugs. It would probably take a couple of years until it beomes stable, if the extent of this change can be compared to Unicode conversion they went through with B9.

And, lastly, the issues with Citrix printing are really unrelated: there will always be architectural issues with data transfers. It used to be "printing under Citrix", now it will change to "opening PDF's from WEB Clients" - no difference.

My belief, that this WEB thing is nothing but a marketing-driven mistake, still stands.
 
Okay after all this web bashing I feel inclined and obligated to say something...........stop the sillyness.

We can all start another holy war over what interface is better, Win32 or Web but the fact of the matte ris that JDEdwards, Oracle and PeopleSoft and hundreads of other vendors have all gone web so we have 3 choices: (1) Accept it (2) Complain about it even though we work with it every day and confuse not only ourselves but all those customers out there or (3) Find new careerr where we are 100% happy with everything.

Truth of the matter is the JDE web client is pretty good and doesn't use all the much bandwidth (I don't know how much it uses and I don't care since it's never been an issue). Just spend the time tuning it and I'm sure we'll here less crying about this subject.

Now when it comes to bandwidth who really cares? Where on our planet do we not see an EXCESS of bandwidth today? Very few places. The original poster I noticed was from Tyco. Tyco? C'mon they must have more bandwidth than MCI! I'm not talking dial up I mean dark fibre and LAN extensions that circle the planet.

I've got 100's of web users on a simple 2 way Intel box all running just fine. Users are happy as pigs in $@#$%. Web client also runs just fine over a 56K modem so what's the argument? Are people really afraid to learn a new technology here? Are we so afraid that all our skills and expertise in Citrix may go out the Window (pun intended) and we may actually have to pick up a manual?

As for using Citrix to run Web - yet another marketing attempt that unnecessarily complicates our lives.

As for heads down data entry on the Web.......usable on 810, much better on 811, excellent on 811 SP1.

I hope we (list people) haven't deterred anyone out there from moving forward with the web.

Bye bye Citrix.

Hello Web.

Long live OraSoftEdwards

Colin
 
I, for one, am not afraid to admit that radical changes frighten me. In more ways than the ones you mentioned. Although being forced to RTFM every so often, is a good enough reason in itself. ;-)

And when someone says "new advanced technology", when leaping five steps back in any measurable direction, I just do not buy it.

Technically, I am not "compaining" - I'm just trying to affect the new technology selection process at Oracle. Someone must be listening...
 
Allow me to be the first to rise to the bait... I would have to agree with
most of the other posters, the web interface on its own isn't an ideal
solution.

The original premise behind having a web interface was the fact that it was
supposed to be a thin client, and this is definitely not the case with the
current implementation. It all looks very pretty, and works fine in a LAN
environment, but the performance over any sort of WAN link from my experience
is poor to say the least.

And as for bandwidth, well I have lots of clients who care, and aren't
swimming in an excess of it. For these clients with multiple remote sites,
the network infrastructure is one their biggest costs, and would balk at the
cost of putting a 1Mb link in for four or five users. In this context does
it not make sense to investigate solutions such as hosting IE on Terminal
Services/Citrix?

The problem at the moment as I see it is that there aren't enough options
being given by OraSoftEdwards except to throw more bandwidth at this. As a
previous poster noted there was originally three types of client available:
JAVA, HTML & Fat. So at least you had an option based on the type of user
based on their type of activity, network links etc, and give them an
appropriate client type. And I don't even rate the 'Interactivity Level'
option either!

I would doubt that most of the 'web bashing' posters would be afraid to learn
the new skills required to implement the Web interface, but for many on 810
and below the Win32 client still offers them the best solution. And the lack
of an alternative to the web is scaring some clients from taking the jump to
811.

I hope this thread has given people considering the web some real-life
experiences, and also some realistic expectations in terms of bandwidth
requirements.

Regards,

Kieran Fitzgerald
 
You beat me to it, Colin! I would have to agree with your point that it is going to happen and all the whining in the world won't make it stop. I would, however, be concerned if I derived a significant portion of my income from the sale of tools which work primarily with the existing fat client technology. Lots of work ahead for some, but that is a good thing.
 
Yes, I believe, that those of us, who sell tools, are now beginning to take advantage of this opportunity. ;-)

On the other hand, whining may not stop it, but changing customers' attitute and lobbying certainly may.

And I would not blame those complaining, when the HTML client is finally ditched (not "if").

As I said, it is my firm belief, that WEB is a step back in very many respects and, as someone has suggested here, when it's without any alternatives, it makes many customers worry. Quite justifiably, I should add.

And, of course, if it's one of a few available platforms, then yes, it may be superior is some respects ("probably" - I just can't think of any right now ;-) and then I would only applaud it.

Tell me what happened to the Java Client? - following your logic, it was also an excellent open_standards_based, leading_edge_technology choice. And it was substantially more interactive, delivering >95% of the Fat Client functionality to the WEB at the time of its inception, something that WEB Client is only getting close to now, after 5 years of endless improvements and bug fixes...
 
About ditching the HTML client, my tea leaves do not swirl that way. I am self-training on J2EE. In my opinion, fat client is dead and I won't miss it.

Re: the java client. It was a version of the windows fat client written in another language (java). Versions diverge, so one of them had to go. It used a database access technology that delivered no benefits over existing technologies and it performed worse than existing choices. Both fat clients have one incurable problem -- they do too much IO or jdenet to work on a WAN. The java client didn't help -- it was worse than the windows fat. The java client was kind of cool to watch but it required a larger machine with more memory to support it, it ran more slowly, and it required as much or more more network bandwidth than the windows fat client. No positives, lots of "sames" or "negatives". It got tossed.

I recall that the java user interface looked a lot like the windows fat and it worked the same way. The HTML client looks different and works different from the fat or the java client.

When I can run a benchmark on the HTML client with a network sniffer I will have a better idea about the network footprint and the pieces that compose it. Next month, maybe.

[ QUOTE ]

Tell me what happened to the Java Client? - following your logic, it was also an excellent open_standards_based, leading_edge_technology choice. And it was substantially more interactive, delivering >95% of the Fat Client functionality to the WEB at the time of its inception, something that WEB Client is only getting close to now, after 5 years of endless improvements and bug fixes...

[/ QUOTE ]

In a fit of something, I nicknamed the guy who developed the java client, "Captain Internet". After all these years, I regret demeaning him and his effort. It was a mighty effort and he had to overcome a lot of internal politics to keep going. He also developed it twice. The first one didn't work for some reason, the second one did -- and then they killed it. Takes a pretty tough guy to do that and keep on going. I have a lot of respect for that kind of determination.

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

Richard Jackson
 
I don't think you understood my comment the way I meant it - I didn't mean that basing something on open standards was by default taking you to the leading or bleeding edge and that it would be "cool" or "better" because of it. I was simply stating the obvious - they currently have a proprietary toolset integrated with several off-the-shelf products, and it can be very good in its own right, but it is absolutely dated. For that matter, so is the best available web client technology for even 8.11 SP1. WebSphere 5.0 is coming off support in September, yet until 8.96 they won't support WebSphere 6.0. As far as I'm concerned, the primary advantage to 6.0 will be support for a better JVM than 1.3.1. Multithreading your garbage collection will certainly be a boon to performance, though this does nothing to correct the development of hefty java script for the desktop client.

I forgot to mention that Java has been around for about 10 or 11 years now, not exactly qualifying it in the category of "latest and greatest". Give the developers time and they will eventually get it right. Apps delivered over HTML aren't going away - look at Microsoft with their sudden interest in "Web 2.0 (1.0 redux)". Windows Live? Office Live? Seems like a feeble attempt to latch on to a "fad", but you don't even have to read between the lines to see they are embracing SaaS (Software as a Service). How would they deliver this technology? How else, the ubiquitous HTML browser with plugins ala JScript, ActiveX + XML data formats, etc. Nothing new here, either. Once again, give the developers time. Also, the customers will demand incremental improvements.

None of that stuff will matter in a few years as Fusion Apps takes hold and is renamed to something everyone will have rolling off their tongues. The JDE product manager stated in the most recent Quest magazine that eBusiness Suite, more often than not, contained a superset of the functionality of EnterpriseOne and by default would win out over E1 in most regards as they develop the "next big thing". The winds of change are blowing.
 
You have, inadvertently I am sure, supported the premise I used in my argument against HTML:

"but it required a larger machine with more memory to support it, it ran more slowly, and it required as much or more more network bandwidth than the windows fat client"

This bit certainly brings the current HTML client to mind...
 
By the time they make it to Fusion, it will probably be all C## anyway, so it's certainly not likely to matter. ;-)

I was just trying to say, that "dated" is not necessarily a hopelessly bad thing. I would rather see the current cart improved, than an attempt to jump the carts during the ride...
 
OK, I have to jump in here. I don't know where the 1MB per page is coming from. And as far as I know the JDE web client runs no java on the workstation - it's all on the server.

Here is a very simple way to see how much bandwith you are using for JDE:

1. Close all apps so that nothing is using your network.
2. Open IE
3. Open the Windows Task Manager
4. Go to the Network tab and add the bytes received column (and the bytes sent if you like)
5. Log into JDE web and see what numbers you get.

Here's my little test:


Login to JDE: 30,000 bytes

Type p01012 into the fast path, click find, and select any record: 40,000 bytes

For a grand total of 70,000 bytes.

Even after clicking close and opening a few more AB records the byte count barely goes over 100,000 bytes. I know that's not Order Entry, but it shows that the network bandwidth used isn't that much.

Then, just for fun, open up MS Outlook and see what numbers you get.

I also tried this: www.cnn.com. That was 500,000 bytes.

For all the users complaining at remote offices - tell them to quit sending/recieving big email attachments that are jokes, quit streaming media over the internet, quit sufing the web, etc.

Sorry, unless JDE is the only thing a user is running, then it's probably the least of your bandwitch concerns.

Andrew
 
Back
Top