Okay it’s Xmas Time so I wont flag as spam, but it’s just for this time.

Basically : the bottleneck in terms of performances but also development and complexity in any enterprise application is the Resource Access and the I/Os. In our 5 software layers architecture, the access to the I/O is the integration layer while the database actually is the resource access.

The main objective of development frameworks for enterprise systems, such as EJBs and Hibernate, is to save the developers from being bothered with SQL and actual Database Physical implementation.

The aim is for application developers to only focus on the business part of the development so that they can bring a real added value to the development. This type of proposal sounds like heaven choir to management ears : “developers are more productive and can really focus on business problems”.

The problem is that these frameworks are extremely heavy (Entity EJBs are a disaster in that respect) or abstract too much complexity (Hibernate) to the user.

While developing it’s great : you save a lot of time as the gory details (SQL request, DB Tables implementation) are hidden by the framework. It all works well on the developer local version of the server.

The problem appears when the solution is tested on a server with many concurrent users.

The actual interface development with the database is completely delegated to these tools. You end up with a layer of software automatically generated that hardly is optimised. You could have (i’ve seen this) thousands of objects incorrectly read from the DB flooding your memory and making the application slow as hell for all users for a mere delete. You also get SQL requests that are not optimised, tables that are not properly indexed etc …

Médéric told us that whenever he is asked for consulting mission regarding Performances, experience has shown that these always are the main suspects, in that order. Integraation as common mistakes are made there and database as this is the place where to search for potential improvements.

Application problems may be in the form of multiple requests (DB, Network, etc …) while a single global request would have done the trick. Standard development design patterns for distributed applications must be applied here (Facade etc …). He gave us an example of an application doing 19 networks call to a Web Services. Changing the API of the service to have the correct granularity have saved 80% of them reducing the average request time from 25s down to 3s.