Acumatica 4.0 - what can be the design of the ERP, and how to optimize the performance of complex applications

Hi, Habr!
Not so long ago, we have released the official release of Acumatica 4.0 - a new version of our cloud ERP products and application development platform. Under the cut - a few words about why this is a big step forward for us and due to what we have managed to significantly improve the speed of our ERP-system.


First, we significantly reworked the UI of our applications.

It was


It became
')
In general, design is the weakest, as a rule, place for all complex systems. On the one hand, you want to cram in as much functionality as possible, on the other hand, all of them are subject to visual simplicity. In addition to the visual part, we have worked hard on the navigation inside the application. Reduce the number of clicks for performing transactions, add “favorites” for the most frequently used functions and improve navigation between bookmarks - these are the main tasks that we set for ourselves while improving the design. If anyone wants to see more screenshots of our application - please , it turned out really cool.

Secondly (and for many this is the most interesting) - we have significantly improved the performance of our applications.


The graph clearly shows how the opening time of the screen (page) in Acumatica 4.0 applications has decreased compared to the previous third version. In addition to the significant acceleration of application performance, we significantly worked on application performance and were able to double the transaction rate.
But to achieve such an increase in productivity was not very easy.

First of all, we identified the weakest places in terms of performance:
• The system too often accessed the SQL server. In the process of working with the application, the user constantly requires various objects, whether they are suppliers, internal codes, or warehouse search. And, since the cache of complex SQL queries was destroyed immediately after returning the server response to the user, the next approach to the server caused a repeated appeal to SQL.
• Re-generation of the interface part of the page each time the application server is accessed. Acumatica does not look like a regular website or a typical browser application. For ease of operation and interactivity, this is more of a desktop application, but with a browser user interface. Naturally, for this you have to pay a high frequency of calls to the server. At each of which an object copy of the page was previously recreated on the server. Although it is already present in the user's browser, and we are not going to redraw most HTML.

The first problem was solved with the help of caching. As practice has shown, after the end of the previous request, after the expiration of 1-2 seconds, the next request from the same user comes to the application server. This is embedded in the interface - you fill in the lines and, most likely, constantly refer to the same objects. Accordingly, we simply decided to keep the cache of requests alive a little longer than it was before. That is, while the user is working with this screen, all repeated queries with the same SQL text, parameters, sorting will be retrieved from the cache and will not cause another call to the SQL server.

We considered two possible implementations of the caching mechanism — a global, user-independent, almost a copy of a DataReader followed by the creation of objects on demand, and a user local, with storage of ready-made objects. The second option was more advantageous in performance, so we stopped there. Was it possible to make a global object cache? In our case, this is not possible, because different users in our system have their own access rights, and the objects may look completely different for each of them.

The existence of the second problem is due to the fact that we have very complex pages. To create a screen, it takes up to a second of server time. To return an HTML user, you need to transfer several hundred kilobytes, in order to compress HTML to tens of kilobytes, you must also load the server. And although the pages are customized for each user with their own access rights to data and tools, after analyzing them we were able to identify the static component of the page and the dynamic one. Static is generated once and gets into the browser cache. Subsequent downloads of the page will get it from the cache, and only a limited request to configure it and load the data will be sent to the server. Where it will not be necessary to recreate the entire infrastructure for generating HTML, and you will not need to send it to the user. By the way, about the browser cache. It turned out that JavaScript, which we have already been static for a very long time and is the same for all pages, recovering from the cache is still recompiled, which can cost up to a second of time on the client. So in 4.0, we used another obvious, but not easy to implement optimization - we carried our script into a separate frame, which is constantly present in the browser window and is not overloaded when navigating between pilgrims.

In addition, we have modified our pages. Due to the use and the fact that they applied relative positioning instead of absolute, the screen is remarkably scaled to fit any screen size. So Acumatica is quite ready and with might and main used on mobile devices. Of course, this required some improvements in addition to the layout, for example, a problem with the lack of the ability to double-click. Now, wherever it is impossible to do, in our interface a separate selection button is simply added.

“The Four” is a great achievement of our engineering team, which has done a great job, but is already thinking about product development further. The beauty of working with ERP is that it is an extremely popular business tool that can and should be brought to perfection further, be it a revolutionary (once) transition to the cloud or improvement of the application.