ExtendedDataTable Vs DataTable

I am currently using Richfaces 3.3.1 with in my seam application and here are few things related to ExtendedDataTable that are worth sharing.

If you are working with a simple Data Iteration(table) with say 5 columns of data, the rendering times for ExtendedDataTable(EDT) and DataTable(DT) appear to be similar. In this particular case using EDT gives you the biggest bang for the buck with all the functionality that comes with it. But, as the number of columns of data in your table increase the performance become more of an issue. Let me explain...

In the application I am working on, we have a screen that is critical part of the whole application and usecases have shown that the user will spend majority of their time on this screen. The screen contains a table with about 18 columns of critical data. The user is allowed to sort, launch some actions from the context menu etc. None of the fancy stuff like the 'grouping' or re-arranging of columns etc. (For the time being, until we have some more scope creep)

We are currently in the performance enhancement phase of development and I noticed that converting the screen from EDT to DT with pretty much the same functionality reduced the rendering time of the table by almost half. I did this using FireFox console output feature that will output to FireBug console. This is the best way I have found to check the elapsed time of different parts of the screen. I am planning to cover FireBug debugging in a different blog post.

To give you some numbers;

• EDT render time 1612 ms and DT render time for the same data 916 ms. That is pretty significate when you are talking screen delay, especially if you have to deal with KPI's like we do.
  
• Some actions on the screen just refresh the list or table using the Ajax "reRender" attribute available. This happens to update "Status" of a row lets say and the re-rendering times for this EDT 600ms and DT 200ms.

So, if you

• Need the extra features offered by ExtendedDataTable like "Group By" or "reorder columns" etc
  
• Displaying a small number of columns
• Not a heavy usage screen

Then go ahead and use ExtendedDataTable's.
Else, stick with DataTable's for the time being.

When and if I try the latest build of Richfaces and notice any significant improvement from EDT, I will do a follow up to this post.

If any of you have found better ways to handle this issue of EDT or other performance improvements that can be attained, please share.

Scrolling for RichFaces ExtendedDataTable

For those who are not familiar, RichFaces is a UI/Ajax component for JSF applications. The latest version of RichFaces is 3.3.1 (at the time of writing this post).

If you work on Web application a lot, you often have to create a table with content, for example: list of results for a search or list of items in inventory etc. Among the several options that are available via richfaces for this purpose, one of the newest is a Extended Data Table. Extended Data Tables are very useful and have several features built-in like sorting, grouping and column re-order, just to name a few. All of this is does mostly on the clientside, using JavaScript from jQuery and other javascript packages.

One of the main drawbacks of this component Extended Data Table is scrolling. You can scroll vertically, but not horizontally, so if you have more columns than can fit on your screen realestate, then you are out of luck. The extra columns will be hidden and you cannot see them, unless you rearrange or remove some columns that are currently in view.

I am not sure, if someone has a more eligent solution for this, or if RichFaces group is working on fixing this issue, but I have figured out a javascript/jQuery resolution for this issue. The following javascript function that will enable scrolling on ExtendedDataTable.

in seam application

/**
* CSS manuplation to enable horizontal and vertical
* scrolling on RichFaces Extended Date Table.
* @return
*/
function enableEDTScrolling() {
var selector = ".extdt-outerdiv";
try {selector = eval(".extdt-outerdiv");} catch (e) {}
jQuery(selector).css("overflow", "auto");
}


in other jsf

/**
* CSS manuplation to enable horizontal and vertical
* scrolling on RichFaces Extended Date Table.
* @return
*/
function enableEDTScrolling() {
var selector = ".extdt-outerdiv";
try {selector = eval(".extdt-outerdiv");} catch (e) {} $(selector).css("overflow", "auto");
}


And invoke the function at the end of your page like surrounded by the normal javascript script tags.

enableEDTScrolling();


Useful links that I found related to richfaces:

LiveDemo - Good live demostrations of richfaces components with code examples and notes.

Source Code for the Live Demo web site - I find this very useful when I am trying to figure out how it done with backend etc.

Load testing Seam application using JMeter

Here are a few links to explain the term mentioned in the title;

1. Seam - JBoss Seam -

Fairly new web framework as an answer to Ruby on Rails from the Java community. Built in support for Web 2.0 technologies like AJAX, Jquery etc.

2. JMeter -

Open Source Load testing application from Apache. Very powerful but not very user friendly, slightly higher learning curve than it should be.

If you are interested in Load Testing a Seam Framework application using JMeter and you google'd for it? You are likely to get several useful hits. This blog post is an attempt to group some of this knowledge in one place and some added finding while trying to do this.

Assumptions:

- Existing seam appliction that needs to be load tested.

- Basic knowledge of JMeter and its functionality.

Lets Begin:

Generally, load testing usingn JMeter is pretty straight forward, but when attempting to load test a web application, thinks get pretty complicated and involved. Creating the page hits manually within JMeter almost become impossible. The easiest way I found to do this is to have JMeter record your actions on a web browser while you browser the application and capture all the necessary information for you automatically.

To do this you will need to use a feature called HTTP Proxy Server in JMeter. Here is screen shot of what my proxy server looks like when it is ready with all the setting for Seam.

Follow these steps to get your HTTP Proxy Server setup correctly and recording your web app;

1. Add a Thread Group to your Test Plan and give it an appropriate name

2. Add a Recording Controller to the Thread Group you just added.
3. Add a Http Default Request to Record Controller
4. Add a Cookie Manager to the Record Controller as well
5. Add a Graphic Results or some other results viewer to the Record Controller, so that you can see the output later.
6. Now to the workbench on the bottom, add a new HTTP Proxy Server and configure it so that it looks like the image above.

Your Test Plan will look something like the image below. If it does not look exactly like it don't worry, it is possible you are on a different version of JMeter and the icons or naming convention has changed.



Time to Record:
If you followed the step thus far, you should be able to START you HTTP Proxy Server and open your browser leaving JMeter open and while you move around in your application watch the JMeter record all your actions into the Record Controller.

When you are done recording a few pages or actions, shutdown you browser and return to JMeter, now you can Stop the HTTP Proxy Server.

The recorded page will appear something like the image below. There are some extra elements in the image below that will be explained later, but general structure should be similar.

If you have made it this far, great, hang on we are almost there.

CID:
If you are working with JBoss Seam, you should be exposed the concept of a Conversation and a ConversationID (CID) for that matter. If you don't please refer to the Seam documentation, because this is out of scope for this post.

If you don't have conversations in your application, you can skip this section and move on to the ViewState section now.

You will have to go thru each record page in your Test Plan, when you find one that has a request parameter of "cid = j_id4", the page just before this one is of importance to you. Remember, the page that is right above this one, if this is X then X-1 is the one that you need, because the response of that page would have created a cid and passed it in the body.

Extraction Step: To the page X-1 add a "Regular Expression Extractor" and setup it up to look something like the image below.

This Regular Expression Extractor will extract the cid from the X-1 page response and store into a variable CID at runtime. For the rest of the page that follow this one, you will need to change "cid=j_id4" to "cid=${CID}", so that the CID is correct for the pages when the script runs during load testing. Continue this conversion until the page that does not have cid in its parameters anymore. This means that the conversation has ended and new conversation is beginning possibly. At this point, you start the 'Extraction Step' and repeat the process.

ViewState:

When I first started to create attempting to create a load test for Seam app, I was sure that CID is the only important parameter to be passed around, but boy was I wrong. Conversation or no conversation, you will still need to handle the ViewState, for your Load Test to work correctly.

You will have to go thru each record page in your Test Plan, when you find one that has a request parameter of "javax.faces.ViewState = j_id3", the page just before this one is of importance to you. Remember, the page that is right above this one, if this is X then X-1 is the one that you need, because the response of that page would have created a viewState id and passed it in the body.



Extraction Step: To the page X-1 add a "Regular Expression Extractor" and setup it up to look something like the image below.

This Regular Expression Extractor will extract the cid from the X-1 page response and store into a variable VIEWSTATE at runtime. For the rest of the page that follow this one, you will need to change "javax.faces.ViewState=j_id4" to "javax.faces.ViewState=${VIEWSTATE}", so that the VIEWSTATE is correct for the pages when the script runs during load testing. Continue this conversion until the page that does not have cid in its parameters anymore. This means that the conversation has ended and new conversation is beginning possibly. At this point, you start the 'Extraction Step' and repeat the process.

That is it:

You are done, now setup your Thread Group one user for one cycle and add a "View Result Tree" to the Record Controller, this will enable your to examine the results and all the contents of the pages when the script runs. You will want to do this just for the first run to make sure it runs thru without any problems. Once you are sure it is running without any problem, you can right click on the View Result Tree and disable it while running the script for load testing with multi users/threads.

Hey you made it! Happy Testing.