.NET performance problems

[joerocket]

Looking for tuning documentation relative to the .NET User Interface. Any comments on .NET UI experience also appreciated.

We love the additional functionality, but are having a hard time with an "improved" interface that is significantly slower than the GUI we currently run.

Even on top-of-the-line client hardware (dual core CPU, 1GB ram, Gb NIC) performance is not good, hitting the local CPU very hard, particularly for a client/server application.

We are upgrading to a new Linux server (single tier) and eB2.1, so it made sense to upgrade the interface. Server side processes are running better (2x-5x faster) than the old platform, so I am confident in the Hardware/DB configuration.

I am hoping we are the problem, but if others are experiencing the same thing, we may pull the plug on this part of upgrade.

 

[gatsbyinca]

Hi,

I just noticed this post and I'm quite interested in how things are going for you with your upgrade. We are experiencing the same thing with the .NET...we are underwhelmed!

I have a document that makes suggestions for modifying the client browser settings. It was provided by the consultant who installed the .NET UI for us...but it’s openly available from QAD in “MFG/PRO Installation Guide – QAD User Interfaces”.

When we raised this (performance issues) with the consultant, his response was along the lines of ...

"Well, that's .NET / Microsoft, what do you expect?"

... not very encouraging!!!

I'd definately like to hear how things are going for you. We are in the process of testing the system for a go-live early next year. Our hope is to get all users on one interface (currently we use GUI & DT), and the hope was that the interface would be .NET. I don't know if this is possible for our high-volume data entry folks...they will probably end up back on GUI.

One thing to consider is that .NET will be the only interface for the new Financials module (eB3?) due out towards the end of '07. That's going to be interesting.

 

[joerocket]

It's been 3 weeks since we went live on eB2.1 and .NET

In general, people who need to get data out love it. People who input data hate it. Too slow. (We are coming out of a GUI environment that navigated as fast as CHUI)

My manager seems to get the brunt of the complaints. He's threatening to roll out GUI again.

This week we started showing users the Character option within .NET. In hindsight, I wish we would have included this in the user training.

We still have several open issues with QAD, for bugs that only affect the .NET., but I'm running out of patience for a product that was suppposed to be ready.

Happy to discuss in detail if needed

 

[gatsbyinca]

I would love to discuss further...here, Q-Village, the PEG or in any other forum!

We have some open support calls as well. Maybe we have some in common!

Our situation is similar to yours...GUI is used locally and it performs very well (as good as ChUI from my previous experiences). Remote users are using Desktop. I would prefer to stay away from ChUI as it's never been used in this company and would be viewed as a backward step I'm sure. It's another set of keystrokes for starters.

Is it acceptable to discuss support calls on an open forum like this? If so...I'm happy to discuss our problems!

 

[wsong]

I am certain that this issue is not caused by .net

What makes the .net shell slow is the the current eb2.1's architecture, which is what happening at the background of the somehow "Modern" interface.

Step1 It receives HTML request from the .netshell

Step2 It sprawns a new database connection and it still uses the old logic written with chui progress to process both the program logic and interface

Step3 and after that reformat the screen output to HTML page using java + Tomcat + Apache and send it to the .net shell

The step2 and step3 is very costly . That usually requires a seperate machine to a host web server and web application server and business logic files.

The above archetecture is only used by QAD maintenance program. As a contract the new QAD browsers will use the .net datagrid to call the prodataset directly in its latest version, so the performance is impressive.

My suggestion for the remedy is to have 2 linux boxs, 1 for DB and 1 for logic and HTML conversion. Maybe you will have a better performance.

I personally think you would be better if you wait till QAD has transform all their maintainence programs to progress app server structure like what did with QAD financials.

Good Luck

Willy Song

 

[joerocket]

Thanks for the clarification. I suspected the problem was something on the QAD side, not the Microsoft .NET side.

Perfomance of the pure .NET functions (browses in eB2.1) are very good.

We are sticking it out, for now, with heads down data entry using the Terminal mode (a big step backwards).

I agree with your advice - anyone considering the .NET UI should wait for the version with maintenance screens running pure .NET.

 

[wsong]

As a consultant, I hope you as a customer can give a hard kick on those soft buts for me. I also believes they should have solved this 1 year ago!

Thanks for the clarification. I suspected the problem was something on the QAD side, not the Microsoft .NET side.

Perfomance of the pure .NET functions (browses in eB2.1) are very good.

We are sticking it out, for now, with heads down data entry using the Terminal mode (a big step backwards).

I agree with your advice - anyone considering the .NET UI should wait for the version with maintenance screens running pure .NET.