Does anyone have a list of best practices to improve Kinetic Cloud performance?
3 Likes
Nothing. It’s SaaS software.
If you have some specific performance issues maybe someone could help. But this is pretty broad and not actionable as is.
2 Likes
Got something specific that you’d like to see improved? Or provide examples?
2 Likes
Not specific to cloud, but making sure your BAQs use key fields is huge! Even if it works without linking Company, still link it. You will get better overall BAQ performance.
Filter early in your subqueries to reduce the overall number of records. The new Kinetic BAQ editor lets you run each subquery on its own. Do this for every subquery, and try to reduce the number of records in each subquery. Less records = Faster.
Don’t forget the daily blood sacrifice required to simply appease the servers.
10 Likes
There’s an option in the browser to disable performance optimization / memory optimization for specific domains. Turn this on for epicorsaas.com and subdomains as applicable (some browsers take wildcards and some don’t)
Latency affects performance more than bandwidth. Prefer a lower latency connection if you have a choice. Also, CPU performance makes a significant difference. I notice my laptop performs slower. Run the computer in performance mode vs. optimized/power saver.
JavaScript/Browser doesn’t multi thread well. Favor a CPU and performance profile that leans toward higher single core performance vs. multi core. Have enough RAM (make sacrifices to the appropriate gods to obtain said RAM in 2026) that the amount of browser tabs you have open with performance optimization off doesn’t hurt you. Browsers will tell you how much ram each tab is taking, so you can load up a typical workload with populated grids etc. and take a look at memory usage, in my experience 8gb will function, 16gb is the sweet spot for a normal user, 32gb for a power user/dev. 64gb and up for a dev running code auto completion in VS Code, code analysis stuff, debuggers attached to stuff, etc.
Use multiple browsers if you are really really pushing things. Some JavaScript things in epicor will deadlock the browser (like grouping and sorting a grid attached to a large dataset) - this will freeze not just the tab but the browser entirely. A second browser lets you do other stuff while the first one is frozen.
Make sure your browser cache is saving to an SSD, nvme preferably, ram disk if you are a dev and pushing things. (Did I mention "possess adequate RAM?) Make sure your %temp% folder is saving to an nvme, or better, ramdisk.
Reduce number of browser extensions to a minimum. Disable filters like adblock on epicorsaas.com. Set up a local DNS forwarder/resolver cache to speed up uncached name resolution. Have a video card that supports hardware acceleration, as the browser uses hw accelerated rendering in a number of cases. Don’t use windows native scaling or any scaling at all.
Don’t use the same browser for epicor as for normal browsing like shitposting on epiusers.help as those other sites will run background tasks in the browser. If running Windows, do the typical optimization stuff like disable unused resident processes that eat cpu cycles or ram needlessly. Don’t use edge agent unless you really need it. Stop using the smart client. Don’t use crystal reports.
Design your layers/custom apps to be well behaved like the days of yore when CPU cycles and ram were at a premium (are we there again yet?) - when you leave a page, make an effort to clear the dataviews associated to grids on that page if that data is not necessary elsewhere in your app (perform garbage collection). Use REST or BAQ filters vs. client filters so the data is minimized on the wire and in memory.
In the same vein as advice above, always minimize your datasets utilizing LINQ or other filtering early in the design of your EFx or BPM. Be conscious of storing binary data like base64 encoded images or other large blobs in places.
When possible to reduce data sent over the wire, pass a dataset by referencing key field(s) and looking up data committed to db vs. passing it in and out of functions.
If a developer, use Kinetic (2025.2.9?) or above, as there was a significant optimization resulting in a speed increase in this version - specifically relating to any screens using the Kinetic C# Code editor (BPM, uBAQ aBPM, etc.)
9 Likes
Have you found any particular browser to be the fastest for Kinetic specifically?
Chrome/Edge are the officially recommended browsers from Epicor, i’ve not noted significant performance differences between them (they are both chromium-based)
I use Firefox sporadically outside of those two but not enough to note any performance difference. I try to stay inside the recommended browsers, as Kinetic is good enough at triggering edge case scenarios without my input 
2 Likes
It seemed like Edge was a bit faster to me, but I wasn’t sure if I was imagining it. I use firefox right now but idk how long I will stick with it
1 Like
I think what would probably make the most significant difference outside controllable variables like extensions, filters, etc. is JavaScript performance, the grid model grouping and sorting algorithm is atrocious, so testing that against a large dataset would probably yield some interesting results.
3 Likes
Sorting or filtering a grid that has server paging enabled sends a new request for the grid’s data, inserting the latencies of request and response and querying and so on. Server paged grid performance isn’t helped by homebrewed sorting and filtering methods being preferred over native .Net Core methods, but it’s mainly slow because of the reloads.
If you disable server paging, sorting and filtering is (currently) handled at the browser. Sorting or filtering thousands of rows takes <50ms. Compare that to Part’s canned landing grid - In one case I’m displaying the same data plus aggregates like total on hand. For a similar dataset size, sorting and filtering performance is 100x better.
The intuitive downside is that disabling server paging results in a large transfer, except that server paging applies so many requests and reloads that transferring the entire dataset moves less total data.
A big component of that improvement is the data source. Canned data sources are not optimized. Replacing the lousy data sources of poorly performing grids with an efficient BAQ can improve application performance dramatically. One of these days I’ll get around to swapping Part’s landing grid’s shambling data source with mine.
Grouping in grids is an exception though. The magnitude of trouble that grouping’s borkedness can cause is impressive. Honestly it’s best to forget that the grouping feature exists at all, definitely so if you’re on a RAM constrained machine.
5 Likes