E9 Performance Hardware, Data or Programming?

"Basically the same thing" isn't equal to "The same thing"

Just a guess but one is moving material, one is just changing the quantity
in a location. When you move something you are updating at least 2
locations(possibly more depending on what the items are connected to),
quantity adjustment is only updating 1 location. While I don't know the
specifics of what each action does behind the scenes, I suspect there is a
difference with the end result in places other than right on that screen
which is why they use different processes, otherwise there wouldn't be 2
different screens with 2 different background processes to accomplish
exactly the same thing.

There are limits to everything, and the majority of what limits people is
the speed of their server to be able to read/write to the physical DB. This
is not a problem that is even remotely unique to Epicor products, this
problems exists in every application with a DB back end, and is worse the
more robust a data set an application has, always.

As Jose said, disk speed and # of spindles is the #1 thing that has the most
effect on system performance, unless for some reason you have completely
under powered the server in terms of RAM or Processors.


On Tue, Aug 30, 2011 at 11:06 AM, rwhalebelly <
richard.whalebelly@...> wrote:

>
> We are all warned about what to expect from the speed performance of
> Epicor 9 but I am interested about how everyone feels what they believe
> the cause to be.
>
>
> We went Live on Epicor 9.04.506 on March 1st 2011 and have come across a
> few unbelievable problems that I can't believe everyone is not having or
> should I say will have in the future.
>
>
> I believe many of the people on Epicor 9 are new users therefore have
> very little data to highlight the problem. We all read the forum to see
> what a huge (massively expensive) server we need but this is just
> masking the real problem that if not fixed will come back to haunt all
> of us. Personally I believe it is down to the way the data is indexed
> and how that index is used in the program.
>
>
> My proof: Issue Misc Material v Quantity Adjustment
>
>
> So if you have a large DB (10GB or over) do this test yourself using the
> same part number for both and report on your findings
>
> (it shouldn't take more than a couple of minutes)
>
>
> Issue Miscellaneous Material : Time 26 seconds (the
> PerformMaterialMovement method takes over 19seconds)
>
> Quantity Adjustment: Time 1 second
>
>
> It is doing basically the same operation however one is scanning the
> database (ours is 18GB)
>
>
> I have reported this to Epicor and was told no one else has reported
> this as a problem. Is it only me or have we all become so use to the
> lack of response we accept these problems and have stopped reporting
> them.
>
>
> Regards
>
> Richard
> P.S Apology for the long post [:x]
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Useful links for the Yahoo!Groups Vantage Board are: ( Note: You must have
> already linked your email address to a yahoo id to enable access. )
> (1) To access the Files Section of our Yahoo!Group for Report Builder and
> Crystal Reports and other 'goodies', please goto:
> http://groups.yahoo.com/group/vantage/files/.
> (2) To search through old msg's goto:
> http://groups.yahoo.com/group/vantage/messages
> (3) To view links to Vendors that provide Vantage services goto:
> http://groups.yahoo.com/group/vantage/linksYahoo! Groups Links
>
>
>
>


[Non-text portions of this message have been removed]
We are all warned about what to expect from the speed performance of
Epicor 9 but I am interested about how everyone feels what they believe
the cause to be.


We went Live on Epicor 9.04.506 on March 1st 2011 and have come across a
few unbelievable problems that I can't believe everyone is not having or
should I say will have in the future.


I believe many of the people on Epicor 9 are new users therefore have
very little data to highlight the problem. We all read the forum to see
what a huge (massively expensive) server we need but this is just
masking the real problem that if not fixed will come back to haunt all
of us. Personally I believe it is down to the way the data is indexed
and how that index is used in the program.


My proof: Issue Misc Material v Quantity Adjustment


So if you have a large DB (10GB or over) do this test yourself using the
same part number for both and report on your findings

(it shouldn't take more than a couple of minutes)


Issue Miscellaneous Material : Time 26 seconds (the
PerformMaterialMovement method takes over 19seconds)

Quantity Adjustment: Time 1 second


It is doing basically the same operation however one is scanning the
database (ours is 18GB)


I have reported this to Epicor and was told no one else has reported
this as a problem. Is it only me or have we all become so use to the
lack of response we accept these problems and have stopped reporting
them.


Regards

Richard
P.S Apology for the long post [:x]





[Non-text portions of this message have been removed]
Most of the problems with performance in Epicor stem from the fact that they
have a fairly poor Index structure. If you are SQL you can run a Profiler
for say a day or two( NOTE this dramatically slows down your App while is
running)



At the end you can take the results of that and push them through and it
will generate SEVERAL new indexes based on the operations performed by the
users. So say if a users searches a lot by Order , Sales Person it will
create that index if its not already there.

(I have found that this dramatically increases the speed of most of the
system, with the caveat that more indexes == more fragmentation so you have
to maintain them properly)



I am not sure how to accomplish the same on Progress although I am sure
there has to be a way.



Furthermore if you look at the structure of Epicor as a whole, because it is
built on SOA (Service Oriented Architecture) there are many layers that make
up the application (DB (Progress Layer), Data Directives, BPMS, Business
Objects ^ Web Services, UI modules, Customizations, Personalization�s)

That is a whole lot of layers to cross while performing simple operations,
say that each of those layers adds 1 to 100 milliseconds of complexity to
the whole ordeal and you've got yourself one of the reasons why the
application seems to slow.



I will grant that some of the processes aren't written using the best
approach possible (they have many developers all of which code in a
different manner) but as a general rule it is written decent enough.
Throwing more CPU at it doesn't make much of a different because A LOT of
the problem is IO bound ( So adding spindles and bandwidth will usually help
more than adding more CPU), translating all those DARN XML files back
and fourth takes quite a bit of effort.


Check your Disk Queue to see if you are having a lot of delay because your
HD is busy and like I said before throwing Spindles at it should help or
redoing your Arrays. (SSD's help although they don't last long ) You can
also throw more Ram at it and tell your app servers to basically shove MOST
if not the WHOLE DB into RAM. But once again the performance improvement
will not be symmetrical adding 50% more HW won't give you 50% better
performance.



In summary, Epicor is so slow (mostly) because it is so flexible, if we want
speed we are going to have to deal with the fact that it can't be as
flexible as it is.



Just my 2cents.



*Jose C Gomez*
*Software Engineer*
*
*
*checkout my new blog <http://www.usdoingstuff.com> *
*
*T: 904.469.1524 mobile
E: jose@...
http://www.josecgomez.com
<http://www.linkedin.com/in/josecgomez> <http://www.facebook.com/josegomez>
<http://www.google.com/profiles/jose.gomez> <http://www.twitter.com/joc85>
<http://www.josecgomez.com/professional-resume/>
<http://www.josecgomez.com/feed/>
<http://www.usdoingstuff.com>

*Quis custodiet ipsos custodes?*



On Tue, Aug 30, 2011 at 11:06 AM, rwhalebelly <
richard.whalebelly@...> wrote:

> **
>
>
>
> We are all warned about what to expect from the speed performance of
> Epicor 9 but I am interested about how everyone feels what they believe
> the cause to be.
>
> We went Live on Epicor 9.04.506 on March 1st 2011 and have come across a
> few unbelievable problems that I can't believe everyone is not having or
> should I say will have in the future.
>
> I believe many of the people on Epicor 9 are new users therefore have
> very little data to highlight the problem. We all read the forum to see
> what a huge (massively expensive) server we need but this is just
> masking the real problem that if not fixed will come back to haunt all
> of us. Personally I believe it is down to the way the data is indexed
> and how that index is used in the program.
>
> My proof: Issue Misc Material v Quantity Adjustment
>
> So if you have a large DB (10GB or over) do this test yourself using the
> same part number for both and report on your findings
>
> (it shouldn't take more than a couple of minutes)
>
> Issue Miscellaneous Material : Time 26 seconds (the
> PerformMaterialMovement method takes over 19seconds)
>
> Quantity Adjustment: Time 1 second
>
> It is doing basically the same operation however one is scanning the
> database (ours is 18GB)
>
> I have reported this to Epicor and was told no one else has reported
> this as a problem. Is it only me or have we all become so use to the
> lack of response we accept these problems and have stopped reporting
> them.
>
> Regards
>
> Richard
> P.S Apology for the long post [:x]
>
> [Non-text portions of this message have been removed]
>
>
>


[Non-text portions of this message have been removed]