Why Is Epicor So Slow? A Kinetic Performance Checklist

How to find the cause

1. 1Scope it: one user, one site, one screen, or everyone? Note the time it started and what changed (upgrade, patch, new BPM, new BAQ, new users).
2. 2Check whether it is down or slow. Open a simple screen such as a part lookup. If even that is slow, suspect the server, SQL or the network. If only one dashboard is slow, suspect the query.
3. 3Test from the server or a machine on the server's network. If it is fast there but slow remotely, the problem is network, VPN or WAN latency.
4. 4Check SQL Server: current blocking, long-running queries, CPU, memory pressure, disk latency, and whether index and statistics maintenance runs regularly.
5. 5Check the Epicor application server: IIS app pool health, memory, recycling, and the server event logs.
6. 6Review BPM directives and custom code on the slow transaction. A synchronous directive that calls external services or runs heavy queries slows every save.
7. 7Review the slow BAQ or dashboard: remove unnecessary joins, add filters and parameters, and avoid returning all rows to the client.
8. 8Change one thing at a time and measure before and after.

SQL Server and the application server

-- Currently blocked sessions on SQL Server
SELECT session_id, blocking_session_id, wait_type, wait_time, status
FROM sys.dm_exec_requests
WHERE blocking_session_id <> 0;

Common pitfalls

• !Restarting services without capturing evidence hides the cause and the problem comes back.
• !Tuning SQL while a synchronous BPM is the real cause wastes weeks.
• !Running MRP or costing during peak hours makes everything look broken.
• !Assuming all slowness is the network when only one dashboard is slow.