Friday, February 12, 2010

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.

Regex Gem

Although I have been programming for over 10 years now, I often find myself looking up some regex stuff (Regular Expressions) whenever I need to do something with it. I would like to think that all programmers do that at one point or another, but can't be sure :-)

Couple of months ago when I was in a similar situation looking for help online, I came across RegExr. It is very simple but extremely useful website for any one learning regular expressions or looking for a quick regex help to continue with what they might be doing.


It is a flash based application that will allow you try out any regular expression at the press of a button and see the results live. The text in the textarea is just an example and can be replace with what ever you need and run regular expression against that. On the right you have a complete list of all the options available for use in a regular expression along with description.

Best of all it is free. Click on the link above to check it out. If you like it or not, leave me a note of what you think.

If you have found other tools that are similar or helpful with other programming type things, please share.

Friday, November 20, 2009

Richfaces Ajax Polling - Beware

The essence of web 2.0 technology is the Ajax functionality or something similar. Simply put Ajax is just a way to invoke a server side function without submitting or invoking a HTTP POST/GET on the entire page. When the function is complete Java Script is used to update or re-render a part of the screen without leaving it. The main advantage of Ajax if implemented correctly is a better user experience.

  • Users can trigger an action and still continue to work on a web page while there action is being fullfilled.
  • Users can receive immediate validation while completing a form of data like an application, request or servey etc.

Richfaces JSF library provides a lot of commonly used Ajax features. On such feature is Ajax Polling, which is a way to invoke a server side function not from a users actions, but on a time interval. This functionality is ideal solution for web pages where they have to constantly have the most up-to-date information. Some common examples might be stock quotes or bid updates etc.

With RichFaces taking advantage of this feature very easy, simply by a adding a few lines that look like the following.

<a4j:poll id="poll" interval="1000" enabled="true" rerender="quotes,status">

The above line will refresh two elements with id 'quotes' and 'status' every 1 sec (1000 milliseconds). These elements could anything from Rich:Panel to togglePanels. That is it!

The ease is also the problem in this case. Let me explain, it is so easy, that you might end up using it for everything and sometimes for the wrong reason. The simple criteria that I base my decision is "Do you need server side action for information being polled?". In most cases the answer to this question will be yes, but there might be a few instances where the task can be accomplished on the client side. To trigger a simple client side Java script you will need the following like of JS code.

var x = window.setInterval('dosomething()', 500);

Where 'dosomething()' is a Java script function that is being triggered or invoked every half a second (500 milliseconds).
So, if you don't need anything from the server use this approach inorder to avoid all the expensive richfaces rerendering.

Monday, October 12, 2009

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.

Friday, October 2, 2009

Bitter Truth about Wii as Media Player - ORB

Orb - as an application is pretty cool with a simple purpose, provide its customers with an ability to access their media anywhere over the internet.

For those who would love to see their Wii used for more than just a gaming machine, probably have come across tutorials to convert their Wii into a media center without any major changes to the game console. This basically works using the web browser built into the Wii called Opera and connecting to Orb site to access your media. Recent news that updates to Opera browser on the Wii are free makes this an even sweeter deal.

But, just the fact that you are setting up an account with Orb and your media is piped through their server from your machine downstairs or across the room has its downfalls. It works well for pictures or audio etc, but that is it. Video or anything like that is a no go.

Apparently, there is another solution that involve messing with the firmware of the Wii. I have never given this a try, since my research shows that the success rate a depressing 20%.

Hence, for now, no media player capabilities for Wii, just enjoy a good game of Tennis with friends.

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.