Thoughts on ORM and the like

Thursday, January 13, 2005

Performance struggle

Having an Identity Map inside the ORM framework handles the first level of caching the objects - a request for the same object does not travel to the database twice. The second level is to cache 1-to-n references (and make them lazy-loaded). However, there is one more scenario when the performance can be boosted.

Very often we need to show tons of records in a simple datagrid with sorting and filtering. We've had some performance testing, keeping in mind that a decent web application should render the requested HTML page in no more than 2 seconds. In previous version of EP.NET we used to bind the object collections to the list pages (e.g. Project List, Bug List, etc). This proved useful to have some logic during the data binding.

However, this approach cannot be used to archieve the 2-second goal. This is because the collection items are lazy-loaded. That is, their external references, like a reference from the Project object to the associated User object (representing the PM) are not loaded until requested, resulting in a number of additional trips to the database when it is not really necessary.

In an n-tier application (like EP.NET) there always are more or less separate layers, and the presentation layer is one of them. Take a look on what happens behind the scenes when the grid with the request list is loaded:
1) The GUI asks for the available request list
2) The business logic layer decides which projects should be included in the list based on user's permissions and routes the request to the data facade
3) The data facade retrieves the dataset from the provider and converts it to the corresponding collection of objects (RequestCollection in this case) and returns it to the GUI for the data binding
4) The GUI binds the collection to the data grid

Actually, the GUI layer does not need the collection for anything except the data binding, so why make it struggle with additional query requests?
In EP.NET 3.1 we decided to create a customizable query builder which will automatically create complex queries (with sorting, filtering and joining) based on XML query description. This approach not only proved almost the fastest possible way to display a list of objects in the GUI, but also a good foundation for the report generator we'll feature in 3.2. For now, the response time does not really depend on the number of records in the database.
Now, the GUI asks for the request list and receives a dataset with all the required fields read from the data source in one query. With SQL Server it is as fast as a lightning!

1 Comments:

Post a Comment

<< Home