•
(Advanced Edition Only) Struts-compliant code generated by the WebFacing Tool conversion
process which sets the foundation for extending your Webfaced applications using
struts-compliant action architecture
•
Automatic configuration for UTF-8 support when you deploy to WebSphere Application Server
version 5.0
•
Support for function keys within window records
•
Enhanced hyperlink support
•
Improved memory optimization for record I/O processing.
•
Support to enable compression to improve response times on slow connections.
The two important enhancements from a performance perspective will be discussed below. For other
information related to Webfacing V5.0, please refer to the following website:
http://www.ibm.com/software/awdtools/wdt400/about/webfacing.html
Display File Record I/O Processing
Display file record I/O processing has been optimized to decrease the WebSphere Application Server
runtime memory utilization. This has been accomplished by enhancing the Webfacing runtime to better
utilize the java objects required for processing display I/O requests for each end user transaction.
Formerly on each record I/O, Webfacing had to create a record data bean object to describe the I/O
request, and then create the record bean using this definition to pass the I/O data to the associated JSP.
These definition objects were not reused and were created for each user. With the optimization
implemented in V5.0, the record bean definitions are now reused and cached so that one instance for each
display file record can be shared by all users.
This optimization has decreased the overall memory requirements for Webfacing V5.0 versus V4.0. This
memory savings helps reduce the total memory required by the WebSphere Application Server, which is
referred to as the JVM Heap Size. The amount of memory savings depends on a number of parameters,
such as the complexity of the screens (based on number of fields per screen), the transaction rate, and the
number of concurrent end users. On measurements made with approximately 250 users and varying
screen complexity, the JVM Heap decreased by approximately 5 % for simple to moderate screens (99
fields per screen) and up to 20 % for applications with more complex screens (600 fields per screen).
When looking at the overall memory requirements for an application, the JVM Heap size is just one
component. If you are running the back-end application on the same server as the WebSphere Application
server, the overall decrease in system memory required for the Webfaced application will be less.
In terms of WebSphere CPU utilization, this optimization offers up to a 10% improvement for complex
workloads. However, when taking into account the overall CPU utilization for a Webfaced application
(Webfacing plus the application), you can expect equal or slightly better performance with Webfacing
V5.0.
Tuning the Record Definition Cache
In order to best use the optimization provided by this enhancement, servlet utilities have been included in
the Webfacing support to assess cache efficiency, set the cache size, and preload it with the most
frequently accessed record definitions. If you do not use the Record Definition Cache, or it is not tuned
properly, you will see degraded performance of Webfacing V5.0 versus V4.0.
IBM i 6.1 Performance Capabilities Reference - January/April/October 2008
©
Copyright IBM Corp. 2008
Chapter 6 - Web Server and WebSphere
109
