Things to be taken care during design/coding:
1) Do not use datatables where it is truly not required. Even If it is search results table, you can manage with datalist. Go for datatable when you need to have links, buttons within the table
2) Do not use panelgrids, JSF components unnecessarily when you can do the same using regular HTML tags. For example: If you want a static table just enclose with f:verbatim tag and use regular HTML table tags. Reduce the burden of component tree creation.
3) Use facelets instead of tiles.
4) If you have an option to switch for JSF 1.2 or above, please do it.
5) Always enclose the JavaScript, stylesheets withing header tag. Write one filter such as cache control filter (I think such filter is used in icefaces) to cache these files. By doing so browser will not request for these files on every screen load. Trust me, this really helps screen response time.
6) Follow the link http://wiki.apache.org/myfaces/Performance and do all tips mentioned for server side state mechanism. You have to be careful when you set org.apache.myfaces.SERIALIZE_STATE_IN_SESSION as false. Especially in distributed/clustered applications, if the app server is supposed to replicate sessions in both the servers, this should rather be turned on. For our application, we set it to true. The number of views need not be 20!!!. For our application we set it to 5. This reduces the memory consumption in JVM.
7) Write your own state manager and override the method which stores objects in session. The myfaces 1.1.6 and below is having a logic wherein it stores the old views in weak hashmap. Modify your statemanger to remove this behavior.
8) Write your own navigation handler to remove unnecessary views from session. For eg: Once the user has logged in, it does not make sense to retain the login screen view in session. Remove them. For our application, we had our own state manager and navigation handler. We then load a static map which will give the list of view ids that need not be stored in session. When the user navigates from one screen to another, the navigation handler checks if the viewid exists in hashmap. If exists it requests the statemanger to remove the state from session. As far as our state manager is concerned, if a particular view id exists in hashmap, it does not spend time trying to serialize the state in session. This way some time is saved and the burden on the memory is reduced.
9) Use ajax as much as you can.
1) Do not use datatables where it is truly not required. Even If it is search results table, you can manage with datalist. Go for datatable when you need to have links, buttons within the table
2) Do not use panelgrids, JSF components unnecessarily when you can do the same using regular HTML tags. For example: If you want a static table just enclose with f:verbatim tag and use regular HTML table tags. Reduce the burden of component tree creation.
3) Use facelets instead of tiles.
4) If you have an option to switch for JSF 1.2 or above, please do it.
5) Always enclose the JavaScript, stylesheets withing header tag. Write one filter such as cache control filter (I think such filter is used in icefaces) to cache these files. By doing so browser will not request for these files on every screen load. Trust me, this really helps screen response time.
6) Follow the link http://wiki.apache.org/myfaces/Performance and do all tips mentioned for server side state mechanism. You have to be careful when you set org.apache.myfaces.SERIALIZE_STATE_IN_SESSION as false. Especially in distributed/clustered applications, if the app server is supposed to replicate sessions in both the servers, this should rather be turned on. For our application, we set it to true. The number of views need not be 20!!!. For our application we set it to 5. This reduces the memory consumption in JVM.
7) Write your own state manager and override the method which stores objects in session. The myfaces 1.1.6 and below is having a logic wherein it stores the old views in weak hashmap. Modify your statemanger to remove this behavior.
8) Write your own navigation handler to remove unnecessary views from session. For eg: Once the user has logged in, it does not make sense to retain the login screen view in session. Remove them. For our application, we had our own state manager and navigation handler. We then load a static map which will give the list of view ids that need not be stored in session. When the user navigates from one screen to another, the navigation handler checks if the viewid exists in hashmap. If exists it requests the statemanger to remove the state from session. As far as our state manager is concerned, if a particular view id exists in hashmap, it does not spend time trying to serialize the state in session. This way some time is saved and the burden on the memory is reduced.
9) Use ajax as much as you can.
No comments:
Post a Comment