I've been following this thread with some interest because we have been studying the users performance perceptions since the inception of version 8 with great interest. There is certainly no question that the user performance experience is significantly different from version 6 but the interesting question is why. From what we have been able to determine, there are a few core components to the performance issues and some available work arounds. As it turns out, some of the issues are application design decisions some of them are architectural and some are deployment decisions.
As for the application design decisions, three stand out as the source of user performance issues. First is the design philosophy to display the maximal amount of data in a single screen instance. With version 8 and beyond, Epicor endeavored to minimize users having to open multiple screens to access the data that they needed by creating comprehensive hierarchal tabbed screens. The net result was screens with a comprehensive view of the data but that were much more resource intensive to render because of their relative complexity. The second application design decision that affects the user performance perception is the agent based, xml generating print engine. The apparent design decision here was to allow for user defined parameterized and scheduled printing so that you could effectively run unattended reports with dynamic parameters according to a pre-defined schedule. The trade off is performance degradation, sometimes significantly, for real time reporting. The third design issue is the utilization of a five level multi-tiered client xml GUI rendering scheme. Before any client screen can be completely rendered it must interpret the Base, Productization, Localization, Customization and Personalization layers. This design is at the core of the ability to almost limitlessly tailor the display but adds additional complexity and resource requirements to the application
Then there are the architectural issues. At the lowest level there is the utilization of .NET on the client. While .NET is a huge boon for the developer it is, none the less, a JIT runtime compiled environment and, as such, requires additional client side resources for the initial runtime execution. The Epicor client also heavily utilizes the Infragistics .NET GUI toolkit which, again is a huge boon for developers because it provides GUI components with a plethora of available options but it also implies that those GUI widgets instantiate with all the available options and, hence additional code, that may never be utilized by either the developer or the user. In other words, you are loading a lot of possibly useless code.
Finally there are the deployment decisions like whether to deploy the smart client natively or whether to utilize the web client or remote desktop like terminal server or Citrix. Also there is the deployment decision as to the backend DB whether Open Edge or SQL Server. As for the backend, Open Edge utilizes shared memory to communicate with the app servers whereas SQL Server must communicate through ODBC and the schema handlers thus introducing additional communication overhead.
As a practical matter, the majority of the user performance experience is dependent upon the workstation CPU clock speed and the memory bus performance. Multiple cores and network bandwidth are relatively unimportant since the Epicor client is single threaded and the application is relatively efficient with network traffic although there are some exceptions notably tied to the print engine. You can, however alleviate the printing performance issues if you do not required scheduled execution by simply bypassing the print engine and directly attach the report to the DB through ODBC....
Michael
Michael Barry
Aspacia Systems Inc
866.566.9600
312.803.0730 fax
http://www.aspacia.com/
As for the application design decisions, three stand out as the source of user performance issues. First is the design philosophy to display the maximal amount of data in a single screen instance. With version 8 and beyond, Epicor endeavored to minimize users having to open multiple screens to access the data that they needed by creating comprehensive hierarchal tabbed screens. The net result was screens with a comprehensive view of the data but that were much more resource intensive to render because of their relative complexity. The second application design decision that affects the user performance perception is the agent based, xml generating print engine. The apparent design decision here was to allow for user defined parameterized and scheduled printing so that you could effectively run unattended reports with dynamic parameters according to a pre-defined schedule. The trade off is performance degradation, sometimes significantly, for real time reporting. The third design issue is the utilization of a five level multi-tiered client xml GUI rendering scheme. Before any client screen can be completely rendered it must interpret the Base, Productization, Localization, Customization and Personalization layers. This design is at the core of the ability to almost limitlessly tailor the display but adds additional complexity and resource requirements to the application
Then there are the architectural issues. At the lowest level there is the utilization of .NET on the client. While .NET is a huge boon for the developer it is, none the less, a JIT runtime compiled environment and, as such, requires additional client side resources for the initial runtime execution. The Epicor client also heavily utilizes the Infragistics .NET GUI toolkit which, again is a huge boon for developers because it provides GUI components with a plethora of available options but it also implies that those GUI widgets instantiate with all the available options and, hence additional code, that may never be utilized by either the developer or the user. In other words, you are loading a lot of possibly useless code.
Finally there are the deployment decisions like whether to deploy the smart client natively or whether to utilize the web client or remote desktop like terminal server or Citrix. Also there is the deployment decision as to the backend DB whether Open Edge or SQL Server. As for the backend, Open Edge utilizes shared memory to communicate with the app servers whereas SQL Server must communicate through ODBC and the schema handlers thus introducing additional communication overhead.
As a practical matter, the majority of the user performance experience is dependent upon the workstation CPU clock speed and the memory bus performance. Multiple cores and network bandwidth are relatively unimportant since the Epicor client is single threaded and the application is relatively efficient with network traffic although there are some exceptions notably tied to the print engine. You can, however alleviate the printing performance issues if you do not required scheduled execution by simply bypassing the print engine and directly attach the report to the DB through ODBC....
Michael
Michael Barry
Aspacia Systems Inc
866.566.9600
312.803.0730 fax
http://www.aspacia.com/
On Nov 3, 2010, at 8:17 AM, cooner_55421 wrote:
> --- In vantage@yahoogroups.com, Drew Patterson <dpatt78@...> wrote:
> >
> > Good questions, that I don't have an answer to. I asked the question based
> > on user feedback - "this is much slower than Vantage 6.1." Given there are
> > only one or tow people on the test system
>
> Hi Drew,
>
> I finally just accepted that it is slower than users expect.
> Who knows how fast would be acceptable?
> For a long time, I tried everything I read or could think of to speed up Vantage.
> I now just add RAM to clients and use the basic steps in the performance guide. Anything else has been wasted time and effort.
>
> Here, in general...
> People who work more with information, like it because it's easier to access and export data.
> Speed isn't really an issue for them but visibility is.
> Data entry people see it more as clicky and slow.
>
> Bruce
>
>
[Non-text portions of this message have been removed]