Anyone else suprised with how long it takes to load each screen in Epicor Cloud? can I ask if anyone else in on a cloud or public cloud has timed any of the load times against those running on prem…
ie going from password prompt to usable dashboard can take up to 17 seconds
going into ap invoice entry from the main screen up to 7 seconds
anyone else being told that the cloud(azure) load time of 500ms for this is normal and a network access time of 3200ms is normal (in epicor’s eyes)
coming from other near instant systems this feels odd, yes I can turn on caching and other tweaks… but why are we having to do this…!
Not surprised at all and when we stop and think about it, it makes sense. If we take a system that was written to work on a local network and then move the server further away, it WILL be less responsive. This isn’t just Epicor, it’s any software that sends a lot of data to and from a smart-client. To really run in the cloud means to think about where the processing is, where the data is, and where the presentation layer is. If you look at popular cloud products, they don’t use a thick-client. All the work is done where there is a lot of processing power and the presentation is sent to a web browser.
And guess what Epicor is working on right now? Kinetic. Kinetic forms are using JavaScript (Angular) for the presentation layer. What happens to all those Business Objects we’re running on the client today? Poof! Gone. (only on the client though!!!) Besides the JavaScript libraries (which are not small), the only communication will be REST calls.
So to really leverage the benefits of the cloud, I had to leave my on-prem expectations behind. We run Epicor in Azure on our own and the performance is similar to Epicor SaaS. Just moving things into the cloud isn’t really leveraging the cloud. VMs are the most expensive things in the cloud. As we think about breaking down solutions into well-defined services that can be tested individually, handle a single responsibility very well, and scale as needed without a huge capital investment - that’s when you’ll see an improvement in performance, reliability, and maintenance. Once I drank the Kool-Aid, I totally saw the possibilities after I left the old paradigm behind.
Remember that today you’re running BOTH the thick client AND Kinetic. It’s the worst of both worlds. Hopefully we will see better performance when you open the browser and log into Epicor. Again, this depends on how big these JavaScript libraries are. But I know for some small testing apps we’ve done (not-Kinetic), the login is sub-second and Epicor Functions return data very quickly compared to WCF performance for the thick client.
we have not run Epicor on Prem previously, so have nothing to compare to, I’d love to hear back from On Prem users with roughly how long it takes to load various parts of the system… it’s not even our BPM’s or MRP
If you’re a M-365 user, you have a license for Windows Virtual Desktop (other charges do apply…) but you could put the client close to the server and get an RDP experience with less clients to maintain.
but you could put the client close to the server and get an RDP experience with less clients to maintain.
anyone running an azure VM to use Epicor want to post up their ping times… curious how much better you are getting… we’re seeing around 4ms to epicor host, the problems don’t seem to be our site to their site latency, they seem to be the epicor server thinking about it problems…
We are relatively new to Epicor and are on the cloud we have used other cloud systems before, every other day I have a user complain about how slow it is. We brought it up with our implementation partner who shrugged the shoulders and said latency. We are small and don’t have a full-time technical IT person on site which is why we went cloud instead of an onsite server however I feel like I spend half my day waiting for Epicor to catch up with me so I can complete my tasks, probably an exaggeration but sometimes it feels that way . Roll on kinetic
we are much the same, we’re having to employ more staff to get the Job done and forced to enable epicor just to process the normal volume we have (for SO automation)
we’ve had systems running between states before that have been very fast, it feels that the speed is either bad architecture or crapy system hosting… I have asked what sort of hardware they are running the DB’s/processing on without a useful reply, it’s amazing how slow MRP is and that it’s single thread for those running on Prem watching… it’d be very interesting to get some side by side video’s of people with the same data both on prem and on cloud to see the difference.
the shrugging from the partners and staff is all too common as well as the usual “what are you doing” when I reply “I pressed the help button” they don’t have much to say… also a bit suprised we’re still using a 32bit client…
@mgoodwin Have you had the opportunity to try some kinetic screens directly in the browser? Does the performance there line up closer to what you would expect?
We have Azure VMs running Epicor and using Windows Virtual Desktop in the same Azure Region. A ping from the WVD to the Epicor VM is <1ms. We still experience the slowness due to the recent Windows Updates just like other on-prem and cloud users. (Use https://azurespeed.com to test from your location to your region where Epicor is installed.)
As discussed on this forum, the .Net architecture as designed is not cloud friendly. The slowness we feel in the Rich client is more than just latency. There’s a lot of marshalling/unmarshalling of datasets, sending and receiving more data than necessary, etc. Kinetic WEB interface seems to be far more efficient. The architecture is not yet cloud-native but I think Epicor is moving in that direction.
This was not our experience. We ran Epicor in Single Tenant hosted by Epicor, which is similar to an on-prem setup, and ERP was fine (we did have very flat BOMs however). When we moved to the Public Cloud, it was about 20% faster. One of the things that is possible in the cloud is burstable compute. There are some architectural changes that Epicor still has to make to get there but in the cloud, one can scale up and/or out to run scheduling and MRP. I guess you could buy an oversized server for MRP and sit on the excess capacity for most of the day but the advantage of the cloud is being able to scale in/down as well.
I’m surprised anyone wants to maintain clients on every machine.
wow, you’d think such a fast connection would make a difference, guess we wait till our customisations are sorted out then spend some time trying the Web version
the Rich client is set and forget, so don’t find it that much trouble
No. We are running Windows in Azure (Windows Virtual Desktop) and the ping from there to our Epicor servers are < 1ms. It’s basically like being on-prem in the cloud.
The Azure speed test from Detroit to the East region is running about the same speed as you’re seeing in AWS.
Even with Kinetic in the browser, in Pilot 2021.2 now, the AP Invoice Entry application takes >10 seconds just to open. In Classic, this screen opens with no data, in also 8-10 seconds. In Kinetic, I guess since it loads group data, it just took me 13 seconds in this test, just for the screen to open and return control to the user ( me ).
All that to say, do your due diligence, and certainly make no guarantees.
Hmm… I just tried it on my cloud instance. It was about 3 seconds. the FIRST time I ran it took maybe 1/2 second longer. I also swapped from Google Chrome to MS Edge, and got the same results.
If I could figure out why our environment underperforms, like what I sense @mgoodwin is experiencing, I’d be a hero. I don’t want “hero”, I would be ecstatic just to meet expectations at this point. Anything else is gravy. Across the board our performance is not even close to doing that, yet Support keeps telling us, as designed. And obviously, you have a very well performing setup.
PS: It’s the struggle we have. Run test again just now, get 6 seconds initial load time. Random performance swings. We have had a Case reflecting this open for months.
Oh, by the way, web browser access affected by the “Microsoft Windows Update Bug”?
And, I wonder what is the “First-first” opening of the application loading time compared to after it is “cached”. I suppose this is where the heart of the difference is. A 100% difference in timing still seems odd to me, but beats 400% handily I suppose.
PPS: But the real catch here, is even my most basic users, insist to have 2 or more related applications open at the same time. Whether or not they are “linked” is another issue, but the lack of opening applications side by side sure seems to be a massive hurdle, and inexplicably missing from all talks around Kinetic. The user experience is extremely important to the success and longevity and seems missing from the equation. Surely folks much smarter than I have gotten this all figured out. Are we to customize applications to layer related information for each use case? What am I missing?
we will see better performance when you open the browser and log into Epicor. Again, this depends on how big these JavaScript libraries are. But I know for some small testing apps we’ve done (not-Kinetic), the login is sub-second and Epicor Functions return data very quickly compared to WCF performance for the thick client.
. Roll on kinetic 
