How often are you recycling the appservers? And how many appservers do you have? And how is it all configured? E.g. do you x users pointing to abc appserver and certain tasks pointed to z apperservers? it is sounding like an architectural/customisation issue outside the normal epicor speed issue
@richard_cj_gardner here is our APR. It is simple and just runs from print invoices. What was the purpose behind attaching the APR to posting?
Greg
Post a screen shot of the BPM you have to send emails. If you joined your ttTable to your order or invoice table with 5m rows, that would be instant death.
I’m also curious about the posting BPM that uses the Autoprint.
If I recall correctly, printing selected Invoices is very difficult. You can either print one invoice, or the whole group. So if the BPM is set to print them one at a time (based on your description that certain conditions exist on that invoice), it’s going to run slow.
You’d be better off just have the posting process print the whole AR group, and let the Routing style do the selection/filtering.
We had a similar issue with our AR team. What we found out is that the user had Nitro PDF installed and there was a collision between the two (Epicor and Nitro). Invoices were created and sent to Nitro to be sent to customers. IT then installed Adobe PDF and all was good. Could this be the case?
This is tough, there are many factors.
- SQL Standard or Enterprise?
- Virtualization Hyper-V, VMWare
- What CPU do you have
- Anti-Virus Excluding Epicor Folders and Server Files as recommended by Epicor?
- ChangeLog Large?
- Do you have BPMs on Order Entry, what if you turn them off
- Firewall / SonicWall filtering internal traffic?
- Cisco Blades by any chance?
- Backups hourly running? Snapshots?
- Whats your SQL Auto-Grow set at
- Did you limit SQL Memory and leave some for the OS (SQL will snatch it all).
- You pass all the PDT Tests? Set all the T-Flags it requires etc…
I would suggest you get a Trial of SentryOne
when you notice slow-downs you can drill down to the second and it will capture all the SQL Statements ran during that second, shows deadlocks lets you drill down etc…
I worked thus far at 2 large corporations 5K+ employees and currently our database is 600GB and we use APR, but we have no bottle-necks. We have about 2 million orders, 6 million PartTran rows. We process a ton of Invoices, so much that manual entry is not possible – we had to automate with OCR.
Plus users have about 250 emails of reports scheduled, multi-company is running, EDI, 50 users have widgets pinned that auto-refresh every 5min by running various BAQs etc etc…
I know one of Epicor’s largest customer’s database is 1.2TB.
Just to be sure - do you have your email widget in the BPM set to asynchronous?
sales order entry freezes for 30 seconds after each line
We are on Cloud, I have been looking specifically at sales order entry processing. I found that linked forms, in particular our Parts form seems to have the biggest impact, but linked forms cause us 9-15 seconds of “pause” while each form does its thing while processing a sales order. Open a Time Phase, Parts Maintenance, both linked off a part in Sales Order Entry, and observe. Print an SO Ack and observe.
Epicor is not a very solid system in terms of performance, if performance is such a big problem i would say you need to start looking into scheduling processes to be executed off hours, i.e. cos/wip, mrp, posting, order generation etc. etc. you need to look into that and maybe there are some processes that you will be able to take off your server’s hands. I have seeing this time and time again, Epicor will only recommend you to add more hardware, more juice, more x more y but will never acknowledge the fact that the software cannot handle the load. you will probably end up spending quite a bit of money in consulting and hardware with no real results.
@hkeric.wci I’m still reeling at that. Would you mind sharing some of your server setup? I have noticed the times you share a GIF of something that your screens do pop up fast, and that you are running a lot faster than us, and our DB is only about 99GB with nowhere near the number of tasks, etc.
But I have this feeling, as you and others are saying, it’s more than just raw horsepower. I know we could probably do things a lot smarter - I just don’t know what that is.
Also random thought @richard_cj_gardner, you don’t have like MRP or something running in Test concurrently with Production, do you (after a DB refresh)? I say that because I did that the other day, even though I certainly know better and write it in bold red everywhere to remind myself…
i think we all have done that at least once…