Projects:Performance

This project will consist on a number of specific actions on different levels aimed at improving the overall performance of Openbravo. Three different areas will be covered here:

• Specific fixes and improvements in the application: here, all specific changes to improve performance in the application (things like improving the performance of a report, or the import of reference data, or the response times of the windows) will be listed.
• Improvements in the Build Process: the build process is a very important part of Openbravo, and its performance can be greatly enhanced. All improvements in this area will be listed here.
• Checklist of things to consider while developing: A number of things to consider, and best-practices which can be used while developing to obtain better-performing code will be listed here.

Specific fixes and improvements in the application

• Performance of the Import Reference data process. The performance of this process (used mainly in Initial Client Setup, Initial Org Setup, and Enterprise Module Management) has been significantly improved.
• Performance of the PL/SQL standardization phase of the dbsourcemanager tasks has been improved
• Performance of the FIC calls (specially in SETSESSION mode) has been improved, and this improves the response time and reduces the CPU load, for example when the user clicks in a record in the grid.

Areas to improve in the application

Combos

There is a project to replace current combos based on the old architecture with new combos which will use datasource and pagination. More information can be found here

Alerts

Currently, each 50s each client is sending a request to AlertActionHandler to obtain active alerts.

This performs 2 things:

• Counts the number of active alterts for the current user/role.
• Returns the whole set of active alerts.

There is room for improvements in both steps:

• Count could be cached (at session level at least) as there are only two events that can modify it. This would prevent DB queries for the count. The events to take into account to handle cache would be:
  • Background alert process
  • Manual alert management
• Clearly returning the whole set of alerts when the only relevant information in most of the cases is the count is incorrect. Return just count. This is going to be handled as a bug.

Improvements in the Build Process

The Build process consists on three different steps. Each of them can be independently handled and improved:

• Compilation
  • Skip 2.50 windows generation
• Database update process (update.database)
• Translation and system-level reference data management

Checklist of things to consider when developing to achieve good performance