Lack of DMT performance is driving me crazy as I can’t figure out where the problem lies.
Up until three weeks ago DMT performance was acceptable. But since then it has cratered and has now become erratic with simple loads now taking hours instead of minutes. And load appearing to “hang” when nothing happens on screen.
It has taken over 8 hours to load a simple update (one field!) for approx 2500 suppliers across four companies.
Looking at the complete log file, it started briskly enough with RPM between 50 and for an instance of two greater than 200 for about 9 minutes. Then is drops off a cliff and I’m seeing RPM 3,4,5,6,7 for the remaining 8 hours. I can see one period where nothing happened for almost 3 hours and second later period where nothing happened for almost 5 hours!. So the effective load time is about 30 minutes but the wait time is 7:30 hours!
I believe I am located in the same country as the data-center (Australia based on IP address) with ping times of 15ms. Local internet speed is 200MBs each way so I can’t see a bottleneck there.
I do have an Epicor case open but I’m not getting much useful help. Move to DMT64 and they have recycled the application pools out environments but still not making any difference.
Questions
Does having several other users all using DMT affect performance?
Unfortunately with SaaS it’s likely something on their side and you probably won’t find out what it was even if they fix it…
I would definitely test DMT from different client machines and locations if you haven’t already.
Out of the things in your control, I can’t think of anything other than checking your BPMs. BPMs fire with DMT so if you have poor performing BPMs DMT could be slow…
Is it? We’re SaaS so I’m not sure if there’s some kind of server side DMT receiver or not.
Something I’ve learned: DMT update processes freeze up discretely from each other. Which enables kind of a clunky workaround - when a DMT process freezes, cancel it, copy the remainder (don’t include the row it’s stalled on, it’ll process eventually!), open a new DMT tab, and run the remainder there. Rinse and repeat as necessary.
It will be interesting to see what happens to DMT when there are no client DLLs. DMT was built before the cloud and used on LANs mostly. Reading the source and sending changes to the server one-at-a-time was OK then but not for cloud. Maybe someday there will be a way to upload files (or check out of source control) and then execute them at the server.
The recent DMT situation got me started pushing updates from a .bash over REST for some things. I do try to be a good neighbor by dropping a sleep 0.5 between curls.
I don’t think it would be a terrible job to make a new DMT via REST. All the documentation is hierarchically queryable; hit ./api/v2/odata/<company ID> to get services, then (for example) ./api/v2/odata/<company ID>/Erp.BO.PartSvc.json to get service endpoint details. That just gets us halfway back to the Swagger UI, but we can improve the experience if we support globally searching endpoint detail. The trick is determining what fetching those 1,083 endpoint’s detail looks like in a way that’s performant and compatible with being a good neighbor, for us SaaS clients anyway.
DMT was built before the cloud and used on LANs mostly. Reading the source and sending changes to the server one-at-a-time was OK then but not for cloud. Maybe someday there will be a way to upload files (or check out of source control) and then execute them at the server. 