DMT BOO very slow after upgrade from 10.1.400.22 to 10.2.300.5

Epicor ERP 10
1

We have been working with Epicor to determine the cause of a very slow DMT with Bill of Operations. With our previous version 10.1.400.22 (DMT 4.0.34.0) we would see 160RPM for the import using a csv file (12,950 records). With 10.2.300.5 (DMT 4.0.40.0) we are only seeing 9RPM. We have done the usual steps of reducing the file size and even with 100 records, we only see 9RPM. After testing several prior versions of DMT (4.0.35.0 through 4.0.39.0) with the same results and Epicor finding other customers also having slow BOO imports, Epicor released a hotfix version of 4.0.40.0. Unfortunately for us, it did not help in our case and we are still only seeing 9RPM. I pressed to have them try our database which they did and could replicate the issue. However, using the same fields in their demo database, the speed was fine so their position is the problem is somehow with our data and not a DMT issue. One last test we tried was disabling all BPMs which didn’t make any improvement, still only 9RPM. Now Epicor says the ball is in our court and will not offer any further support, we would need to go to professional services. Sooooo, anyone have any other suggestions to help isolate the root cause? Anyone else experiencing similar numbers?

Tim

2
  1. Does the same issue occur if you apply the latest 10.2.300.x point update? (as of today, that would be .10).
  2. Are you running 10.2.300.5 on exactly the same server that you were running 10.1.400.x (so you are comparing like for like hardware)?
  3. Have you enabled the server-tracing to see where the time is actually being spent?
  4. Take DMT out of the picture: if you manually input the data in the client, are you seeing the same execution time (from a server-trace perspective) that you see in the DMT? If so, that would be an application issue (caused by data most likely) that would be investigated by the appropriate support team.
3

Following because we are having the exact same issue but hadn’t called Epicor about it yet.

1 Like
4

I wonder what the size of their test database is compared to yours. If they screwed up on a filter for some validation, a tiny test database wouldn’t see a performance one, but a full size one would.

Rough estimate, how many parts revisions do you guys have in your database?

5

Epicor indicated the hotfix we tried helped other customers with slowness specifically with BOO. Be worth reaching out to them to get a copy to see if it helps with your situation. I would be more than happy to share our copy with you, but not sure if that would be “allowed”.

6

Although our database is small (30gig) in comparison with others, we have 55k parts where 32k of them have at least one revision.

7

I bet the demo database is less than a couple hundred.

1 Like
8
  1. I have not tested that scenario. We have setup out sandbox environment as our old 10.1.400.22 so we could refer back as needed. I can get there, but it would take a bit of time.
  2. Yes, the production hardware is identical.
  3. I will test and report back. Do be aware, Epicor was able to duplicate the slowness with our data on their server, that would indicate to me it’s not hardware, network and the like. Somehow it is data related.
  4. All the other DMT imports we have done all run and feel the same as the previous version, only the BOO is slow…and by a huge margin. Manual data entry “feels” the same, but I do not have numbers to support that at this point. I will do some testing on that as well.
9

Can you provide me the case number you submitted this under so that I can review?

1 Like
11

CS0001317134

Thank you Nathan

12

I’ll put in the support call, just so they know another customer is having issues. Thank you!

1 Like
13

they duplicated the issue using DMT, but, not manually testing as the analyst’s area is DMT not production. The analyst’s most recent question from that case this morning is the same as one of mine–(my last one). If you can enable the server-trace, run some manual BOO tests within the regular client, then some DMT tests and provide that log in the referenced case we can provide troubleshooting this issue for you.

Hope that helps.

14

Without enabling the server trace, I have verified that 10.2.300.5 takes considerably longer to approve and check in than the old version 10.1.400.22. In 10.1.400.22, with a single part, it completes nearly instantaneous. In 10.2.300.5 it took over 7 seconds. Very noticeable.

15

Are you using the same ECO group for all of these checks? We’ve noticed that sometimes one will get really slow, so we make a new one, and it works much faster.

16

Yes, both the manual test and the DMT used the same ECO group. For kicks, I used a second account and reran the DMT. Results were the same with 9RPM.

17

Bummer, was that a new one? Or just a different one?

18

great news; it’s not a DMT issue then. With the server-trace attached to the existing case, we can get the case to the appropriate support team to assist.

1 Like
19

I just tested with a brand new ECO group, outcome is the same, both manual check-in and DMT.

1 Like