Facelet Performance (WebApp Performance)

Posted by Unknown on 6:21 PM
Labels:

Advantage of using Facelet:
Facelets do not depend on a web container.
Facelets have a faster compilation process than JSP since no Java bytecode is generated and compiled.JSP is a templating language that produces a servlet. The body of the JSP becomes the equivalent of a servlet's doGet() and doPost() methods (that is, it becomes the jspService() method). Unlike JSP, Facelets is a templating language built from the ground up with the JSF component life cycle in mind. With Facelets, you produce templates that build a component tree, not a servlet. This allows for greater reuse because you can compose components out of a composition of other components.
Facelets provides templating so you can resuse your code to simplify development on large applications with detailed error reporting.

In terms of facelet performance following tweaks can be done to optimise JSF-Facelet further.

1. facelets.DEVELOPMENT – print debug info for errors (Context parameter in web.xml). Set it to false to remove extra overhead at production environment.

<context-param>
<param-name>facelets.DEVELOPMENT</param-name>
<param-value>false</param-value>
</context-param>

2. facelets.REFRESH_PERIOD – interval compiler checks for page changes – lower values useful during development – set to -1 if you don't want checks made.

<context-param>
<param-name>facelets.REFRESH_PERIOD</param-name>
<param-value>2</param-value>
</context-param>

3. facelets.SKIP_COMMENTS - In production, no need to let comment in rendered html. this will reduce the rendered html size while travarsing through newtwork wire.

<context-param>
<param-name>facelets.SKIP_COMMENTS</param-name>
<param-value>true</param-value>
</context-param>

Your comments/suggestions are welcome

comments (1)

JSF Application Tuning (WebApp performance)

Posted by Unknown on 1:06 PM
Labels:

JSF requires two paths: one to create the tree and one to render it.One of the areas of JSF that We think suffers compared to other models hat it requires two paths instead of one. In JSP,code is compiled directly into Java byte code. That code is then directly executed when the servlet is accessed. As a result, a single path is executed to render the content to the output stream. In JSF, first a component tree is created and renders associated with it. Once that tree is constructed and JSF enters the render phase, the tree is walked completely and content is written to the output stream. Thus, JSF requires two paths: one to create the tree and one to render it.
On plus side it's a cleaner MVC architecture for performing validation, actions, and rendering.

Below are some analysis, suggestions for JSF application settings optimized JSF performance.

In JSF, when the FacesServlet is accessed, it asks its associated view handler implementation to restore or build a view or component tree.. As components are stateful, a new instance must be created per request. Thus, for a very large page with several components, it requires invoking several tag handler classes that end up retrieving the application to get the component which then creates the component by using reflection on the associated class type. This has two impacts to performance.
First, you have to create several components for a given page and each of those invocations require memory allocation, initialization, referencing, setting attributes, etc…very expensive tasks. This also impacts garbage collection by creating excess garbage per request.
Second, it has to use reflection to create the classes and reflection is generally slower than directly invoking the new operator.

Instead of keeping all component as Stateful we could mark a panel group as stateless.
@Stateless
public class UIPanel extends UIComponentBase {
// normal code
}

For an input component, you might mark all input components as stateful.
@Stateful
public class UIInput extends UIOutput {
// normal code
}


Remove Serialization Overhead:
Performance measurements have shown that plain server side state saving (without serialization and without compressing state) comes with the best values. State saving at client side is having security concerns as well as overhead of serialization of entire JSF tree every time.

Web app deployment descriptor entry:
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>server</param-value>
</context-param>


Reduce Session overhead:
javax.faces.ViewState is a hidden field in JSF which gets auto generated when the page is deployed as a web application.JSF keeps lots of information about the current page and previous pages in the JSF state object. This allows all of the Faces components to keep track of their state, and also allows the back button to work. Server side state saving is where the component tree and all component state are stored within the user's session. This entry within the session is tracked by writing a key in the response that is used to look up the entry on subsequent post-backs. By default the value of holding state in a single session is 15.

So, If the view is 5K big, in a single session its holding almost 5MB data.For 1000 concurrent user its almost 4.8GB data we are storing into session (Application memory) is unnecessary. It'll give out of memory for sure as 32 bit Application Server (most common open source servers) can only support max 2GB of heap size (for 64 bit it supports max 4GB heap size).

The numberOfViewsInSession parameter is the big one – this only allows three back buttons inside a faces form.Value shoud be given as per application requirement.

Web app deployment descriptor entries: (Optimize values of following parameters can vary according to application requirement)
<context-param>
<param-name>com.sun.faces.numberOfViewsInSession</param-name>
<param-value>3</param-value>
</context-param>

<context-param>
<param-name>com.sun.faces.numberOfLogicalViews</param-name>
<param-value>10</param-value>
</context-param>



Your suggestions/comments are welcome.

comments (0)

Subscribe to: Posts (Atom)