Performance Tuning - Chapter 1: Architecture and Design

The main challenge with using the Backbase Client Framework to develop web applications is to balance the client-side logic with server-side logic. Rich Internet Applications (RIAs) require more logic on the client, but putting too much logic on the client-side can be a disaster for performance.

There are many reasons for performance issues. This chapter aims at finding these reasons and providing some hints and tips to avoid overloading the client. These performance tuning methods are categorized into four stages, each represents one of four basic steps during the web application development life cycle: architecture, implementation, deployment and server-side optimization. The performance testing is then addressed, followed by a conclusion and reference information.

Architecture and Design

Performance issues should be pointed out at the very early stages of building an Ajax application. In the architecture stage, the goal is to reduce logic at the client-side. This is because Backbase Client Framework uses the Model View Controller (MVC) model and it will create three types of nodes instead of one for every normal Backbase element (some elements may not have all three nodes):

  • HTML DOM nodes in view space
  • Model nodes in model space
  • Controllers as JavaScript objects that match elements in view space

The benefit of having two extra nodes is that this adds object-oriented features and thus improves separation of concern, reusability and extendability of the project. On the other hand, these additional nodes require more time to parse and execute, which takes up more browser resources.

1. Balance out the amount of client-side business logic

The basic rule of client-side Ajax is not to replace all the business logic in server-side. Rather, only common business logic requires that such form validation should be placed on the client. This is a common mistake when developing Ajax RIAs.

Important: Do not do things on the client that the server can do equally well, without losing usability (end user friendliness). For security reasons, all validation should be repeated at the server.

2. Divide client-side architecture into a direct shown part and a logic part

At the client-side, a web page can be divided into a direct visual part and a functional part. The direct visual part can be shown immediately when the page starts to load and the functional part can be shown later. In this way, the perceived performance enhancement helps to improve the user experience.

3. Set up architecture design with separation of concerns

Although this concept has no direct impact on performance, it aids to pinpoint problem areas. Moreover, it allows you to refactor and optimize components and routines more easily, since this can be done and tested in isolation.

4. Create custom container widgets and contained widgets as one

Model nodes with controllers that are present at the client-side are very nice for object-oriented encapsulation. On the other hand, these could be expensive, as they need more space and require more interpretation. As a result, the amount of model controllers should be minimized. For instance, when creating a menu with sub-menus, the usual approach is to create model nodes and controllers for each menu and each sub-menus involving mouse event capturing.

A better way is to create only one model node with a controller for the whole menu bar and catch bubbled events from there. More details are available on Event Order and Event Delegation.

See other chapters:

Performance Tuning - Checklist

Performance Tuning - Chapter 1: Architecture and Design

Performance Tuning - Chapter 2: Implementation

Performance Tuning - Chapter 3: Deployment

Performance Tuning - Chapter 4: Server-side Optimization

Performance Tuning - Chapter 5: Testing

Performance Tuning - Chapter 6: Conclusion

AttachmentSize
performanceOp_examples.zip8.89 KB