ShowTable of Contents
The 3 Main Areas of Form Performance
In pretty much every IBM Forms solution, there exists 3 major areas that need to be understood when measuring form performance.
At a high level these are:
1. The web application that serves out the form.
2. The translator that loads the form into memory.
3. The end users browser.
Each of the above areas greatly impacts what appears to be 'form performance'. The end user clicks a link, and is now waiting for their form to load, if any one of the above areas is slow, then it appears to the end user that the form is slow. When in fact it could have nothing to do with the form.
In this article we'll also discuss what forms design decisions effect the 3 areas mentioned above, and we'll describe some basic best practices in this area.
But first, when attempting to investigate a poorly performing forms solution, one needs to understand all the operations between the time the user clicked that link, and the form showing up in their browser.
The steps are listed here, expanding on our 3 main areas (optional steps are marked as such).
1. The web application that serves out the form.
1.1 The web application receives the request from the user
1.2 The web application authenticates the user (optional)
1.3 The web application pulls the form template from a repository
1.4 The web application retrieves data from external sources (optional)
1.5 The web application pre populates the form template with this data (optional)
1.6 The web application returns the form to the user (but here the form is actually sent to the translator)
2. The translator that loads the form into memory.
2.1 The translator receives the populated form
2.2 The translator loads the form into memory
2.3 The form in memory retrieves data from external sources (optional)
3. The end users browser.
3.3 The browser requests additional resources (images, etc) from the translator (this always goes through the web application)
3.4 The browser renders other content on the page (optional)
3.5 The browser renders the form
As you can see above, there are many steps that contribute the the overall time that appears to simply be the 'form loading'. For example, in step 1.4 above, where the web application is retrieving data from external sources - if this was a slow web service call, then all the downstream steps need to wait until that web service call is done, so during the time the user is also waiting for their form.
When understanding performance it is recommended that one create a list of steps like above for your particular forms solution. Then you should do your best to measure each of those steps to see how much they individually are contributing to the overall time spent. This allows optimization to be focused in the steps that will give the most improvement. For example, there's not much benefit in making changes to a form to gain a 1/2 second improvement when a web service in step 1.4 takes 10 seconds to respond. The focus should be on those areas that are taking up the most time.
How one goes about measuring the amount of time being taken by the various steps above differ, but a few techniques are listed here and based on the results the likely areas that requires focus are discussed:
First we'll start with the last area, as it is often found to be the performance bottleneck.
Testing the End Users Browser
The amount of time areas 1 and 2 take will remain consistent no matter what browser is in use (areas 1 and 2 do the same amount of work the same way no matter what browser you use) - so you can use this fact to help understand where optimization efforts should be focused. For example, if you find that loading your form in your solution with Chrome takes 3 seconds, but in IE8 takes 15 seconds, then you can be assured that optimization efforts are not necessary on areas 1 and 2 (as the test with Chrome shows areas 1 and 2 do perform quickly).
The obvious answer is to tell your user base to use the fastest browser found in your tests.
If you're not able to dictate what browser your end users use, then there are form design techniques that can be used to help alleviate the amount of work the browser needs to do to create and render the form. A form performance analysis tool has been attached to this article as well to help possibly identify what in your form is contributing most to the amount of time it takes to load.
Form Performance Analysis Tool
The Form Performance Analysis tool will provide a report of the number of items found in a form, and their expected cost or weight (as some items take longer for the browser to create than others). Then an overall 'Effect' score is given (Effect = cost * number of items). The larger the number the longer the browser is expected to take to load the form.
Attached to this wiki article are 2 html files. They are meant to be used with an already deployed Sample Servlet that ships with the IBM Forms Webform Server. Once the sample servlet is deployed, you'll find a Samples.war directory likely under:
Place the 2 attached html files (performance.html and js_frame.html) in the Samples.war directory listed above.
Any forms you wish to run in the tool should be placed in the SampleForms directory. The SampleForms directory is also found in the directory listed above. Any forms or directories placed in the SampleForms directory will automatically be shown in the list of forms shown by the Sample Servlet.
To run the tool, hit the URL http://your_server_name:9080/Samples/performance.html
, where your_server_name is the domain or ip address of where you've deployed the Sample Servlet. If you've deployed the Sample Servlet under another port instead of 9080, then you'll have to update the URL accordingly.
The tool will show the Sample Servlet with a list of your forms on the left hand side, and a couple of buttons with a Results text area on the right hand side.
Click on the "?" button on the right hand side to get detailed help on the information the tool generates.
Select a form in the Sample Servlet.
The tool generates an overall 'Effect' score - which is roughly equivalent to the number of milliseconds the IE8 browser will need to create the form / items. So if your form generates an overall Effect score of 8500, then it's expected that IE8 will take 8.5 seconds to load this form. If the report states that 50 date pickers has an effect score of 4250, then over 4 seconds of time is being spent just adding date pickers to your form. So if these date pickers were inside a table, where you showed 50 rows, and each row had a single date picker, changing the table to only show 5 rows at a time would greatly help performance, where the load time would likely be decreased by over 3 seconds when using IE8 due to the browser only needing to create 5 date pickers as opposed to 50.
The effect score will be the same no matter what browser the tool is run in, but the percentage impact is expected to be the same. So in our example above, one would expect a 50% improvement in performance when going from an effect score of 8500 to 4250 no matter what browser is used.
Again, the effect score is an estimation, as every browser / CPU / network combination is different, but the score should give you an overall idea of what in your form is impacting performance the most.
The tool will also check to ensure that on demand page loading is enabled.
Techniques for Faster Form Performance in Slower Browsers
Since IBM Forms 4.0 (and all versions there after), the the main overriding factor that contributes to form load time is the number of form items the browser needs to create and render on the first page. This is what is occurring in step 3.2 above.
Some performance best practices for form design are described here:
Break a large form page with many items on it into many form pages - leveraging on demand page loading. The browser deals with the form one page at a time, so limiting the amount of content we ask the browser to create and render will improve performance.
Use less items on each page
- so use boxes instead of 4 lines (some form conversions result in lines being created, where a box would be better)
- use labels with large amounts of text instead of lots of labels with smaller amounts of text
- if your form has tables, limit the number of rows that are shown at one time.
- some form items are more expensive to create than others, limit the use of popups, date pickers.
- limit the number of items in radio groups and check groups
Items that are not visible still take the same amount of time to create and render as visible items. This includes items inside a hidden panes.
The exception to this is with a switch case, where only the items in the currently active case are created and rendered by the browser, and the content in the non active cases is only created when (and if) the user navigates to those other cases. Switch cases can also be considered instead of breaking the form apart across many pages, the form could be split across many cases. A combination of both (many pages each with many cases) could be used as well for extremely large forms.
Limit the amount of data allowed to come into the form via web service calls - especially if UI is bound to that data.
If you find that the amount of time is consistent between the various browsers, then efforts should be focused away from the browser (and possibly the form), and back into areas 1 and 2.
Testing the Web Application
So we've already measured the overall amount of time the form takes to load within your solution - one can use a simple stop watch to achieve this. Be sure to stop the watch after the form is rendered in your browser, not when a network trace receives the last packet - as there's much more work for the browser to do after that time.
Next you should attempt to measure the time to load the form excluding your web application. Using the Sample Servlet that ships with the Webform Server (which is a very lightweight web application), load your form, and take another stop watch based timing. If the original overall time was say 15 seconds, and the time just in the Sample Servlet is 5 seconds, then you know that 10 seconds is being used up by something in your web application - so likely efforts should be focused there. If the time in the Sample Servlet was found to be 12 seconds, then you know that the web application only took 3 seconds, and efforts should be focused either on the form itself, or the translators in play.
Techniques to Measure Performance in Your Web Application
To measure time in steps 1.1 to 1.6 insert debugging statements in your servlet code before and after each operation, and record the elapsed time.
It should become pretty apparent where the majority of the time is being spent.
Often it's some other external system (either the repository or external data sources that are taking up the time in this case)
- One can consider making sure the form is compressed, so when it's either pulled or saved to repository, it's the smallest amount of data being transferred and stored.
- If web services are constantly being called and the same data is being populated into every form on every form request, consider caching the web service response. This works well for cases when the data does not change - like the list of states in the USA for example.
Testing the Translator
Only once we've removed the web application and the form and / or browser as the possible performance bottleneck, should we consider looking at the translator.
The translators CPU and memory should be measured during form load to see if there's something in the form that is having a drastic effect on CPU in the translator. For example, a large amount of data returning from a web service call setup in the designer using the web services wizard could have a drastic effect on the CPU and thereby performance. See the following article for how to handle that situation: How_to_handle_large_amounts_of_data_coming_back_from_a_web_service_call
Ensure that the translator is properly sized and configured from a memory standpoint for the size of forms being used and expected load. Best way to do this is to look at the translator's console.jsp: http://translator_server:8085/translator/console.jsp
This gives you a few measurements around how much memory is currently in use by this translator, and the number of forms loaded. Pay special attention to the "Loaded Forms From Disk" number, as if that is above 0, this speaks to a translator environment that is not configured properly or is overloaded, as this should only go above 0 in a failover scenario.
Assuming a properly configured translator: The size of the form effects the translator in a few ways.
1. When the form is loaded, the larger the form is the more CPU is required to load the form, if CPU is exhausted, then this form load operation is going to take longer, and the user has to wait. On Demand Page Loading helps a great deal here - be sure that it is enabled if you have more than one page in your form.
2. The size of the form also dictates the amount of space required to hold the form in memory. If a translator is forced hold too many forms in memory that take up more room than it's been configured to use, then swapping starts to occur (a constant reloading of forms from disk), and this uses up CPU - the "Loaded Forms From Disk" value will go above 0 if this is the case.
3. If your environment does a lot of printing - possibly this is using up more CPU than expected, and then normal form requests suffer due to a tied up CPU - possibly consider standing up a specialized print translator cluster.
During form load a small CPU spike is expected, anything longer than a second would be a concern, and possibly the form design changes discussed above should be considered.
In a well designed system with a properly configured translator, and a properly designed medium to large form, one should expect the form to load in 4-5 seconds - one should consider making form changes - or identifying other bottlenecks if your seeing response times well beyond this.
Or at least gain the understanding of where the bottleneck actually exists, as opposed to the normal, 'the form is slow'.