I feel Acumatica could use someone in charge of tuning the site for performance. One of the little discussed dark sides of constant feature innovation is that there can be a tendency for performance to suffer as a result.
For example, I was surprised that there doesn’t seem to be any plan to try to rearchitect the middle tier in conjunction with the move to Aurelia. Acumatica still has a pretty “thick client” approach to its stack, even though it is moving to adopt modern tools like Aurelia. Back in the bad old days of early .NET (remember code behinds?), it wasn’t really an option to asynchronously load the front end. You had to have all your data objects ready for presentation when the front end loaded. With modern asynchronous javascript, this is no longer the case, and so I think it is a missed opportunity to spend all the time to reskin the front end without focusing on the performance advantages that could also be gained by rejiggering the middle tier of the software.
Just as an example, I have been doing some performance profiling in Sql Server when the site loads in the morning from a cold start. This morning, running on a decently powerful local server with a local connection to SQL Server running on its own dedicated server, the time for the site to load was 181 seconds. That was the time from when the login page was requested, to when the login page was presented. If you read these forums, this is par for the course.
I have thrown way more powerful sever configurations at Acumatica (i.e. $20k/month Windows Server + RDS configs with tier 1 isolated SSD, etc), and it barely moves the needle with regards to these issues. in other words, this has nothing to do with hardware and everything to do with what’s happening on the backend of the software.
If you run SQL Server Profiler, you can see that a lot of the startup time has to do with loading Acumatica’s cache with site specific information (Acumatica can have multi-tenant on the same database), and loading this into memory in preparation for login. However, wiih some clever code, we could probably make this load time 5 seconds. All we would have to do is be more intelligent about when we load up the cache and expire it. If we see that user activity always drops off at 11PM, and almost never starts back up until 6am, then the cache should be fully loaded and ready for login at 6am. This is just one example of how, without even implementing any changes to the stack, the login page load itme could be cut to seconds from minutes for all users from a cold start.
There are probably hundreds or thousands of optimizations like this that could dramatically improve the performance of the software, and some which probably wouldn’t really require all that much effort at all. But someone needs to be in charge of pushing back against just pure feature innovation, with a focus on the feature vs. perfornance tradeoff. So I would strongly recommend that Acumatica consider putting someone (ideally a developer with performance tuning background), in charge of pushing the envelope for performance in the product.
