Skip to main content

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.

Hello @rosenjon we have a dedicated team specifically working on performance improvements


Hi @Dmitrii Naumov -

I think that my frustration is that it shouldn’t take 3 minutes for the site to load in the morning. There have been discussion on here about similar issues (i.e. time to load after recompiling code), which is in effect caused by the same issues of reloading the cache.

It seems to me that with better predictive tools (I used the example of the cache being expired in the morning, but there are a ton of other more subtle versions of this baked into the software), you could improve performance a lot by anticipating when data will be needed and pre-caching that in a more intelligent way.

Ultimatley, it would be better to move to client/server model that is more dependent on ligthweight asynchronous data requests and less on monolithic caching (perhaps Aurelia can open the door to some of this). Perhaps it would also be nice if the Acumatica team could share what kind of performance improvements are being made, and also focus on some of these longstanding performance issues and how they might be solved.

 

Thanks,

 

Jonathan


@Mark Franks  that could be a good topic for Coffee&Code, to share what we are doing on the performance optimization side


@stevenhouglum we should have a session on this topic.


Reply