Intel 7xx Servers User Manual
6.4 IBM WebFacing
The IBM WebFacing tool converts your 5250 application DDS display files, menu source, and help files
into Java Servlets, JSPs, JavaBeans, and JavaScript to allow your application to run in either WebSphere
Application Server V5 or V4. This is an easy way to bring your application to either the Internet, or the
Intranet, both quickly and inexpensively.
into Java Servlets, JSPs, JavaBeans, and JavaScript to allow your application to run in either WebSphere
Application Server V5 or V4. This is an easy way to bring your application to either the Internet, or the
Intranet, both quickly and inexpensively.
The Number of Screens processed per second and the number of Input/Output fields per screen are
the main metric to tell how heavy a WebFaced application will be on the WebSphere Application Server.
The number of Input/Output fields are simple to count for most of the screens, except when dealing with
subfiles. Subfiles can affect the number of input/output fields dramatically. The number of fields in
subfiles are significantly impacted by two DDS keywords:
1. SFLPAG - The number of rows shown on a 5250 display.
2. SFLSIZ - The number of rows of data extracted from the database.
the main metric to tell how heavy a WebFaced application will be on the WebSphere Application Server.
The number of Input/Output fields are simple to count for most of the screens, except when dealing with
subfiles. Subfiles can affect the number of input/output fields dramatically. The number of fields in
subfiles are significantly impacted by two DDS keywords:
1. SFLPAG - The number of rows shown on a 5250 display.
2. SFLSIZ - The number of rows of data extracted from the database.
When using a DDS subfile, there are 3 typical modes of operation:
1. SFLPAG=SFLSIZ. In this mode, there are no records that are cached. When more records are
1. SFLPAG=SFLSIZ. In this mode, there are no records that are cached. When more records are
requested, WebFacing will have to get more rows of data. This is the recommended way to run your
WebFacing application.
WebFacing application.
2. SFLPAG < SFLSIZ. In this mode, WebFacing will get SFLSIZ rows of data at a time. WebFacing
will display SFLPAG rows, and cache the rest of the rows. When the user requests more rows with a
page-down, WebFacing will not have to access the database again, unless they page below the value
of SFLSIZ. When this happens, WebFacing will go back to the database and receive more rows.
page-down, WebFacing will not have to access the database again, unless they page below the value
of SFLSIZ. When this happens, WebFacing will go back to the database and receive more rows.
3. SFLPAG = (SFLSIZ) * (Number of times requesting the data). This is a special case of option 2
above, and is the recommended approach to run GreenScreen applications. For the first time the page
is requested, SFLPAG rows will be returned. If the user performs a page down, then SFLPAG * 2
rows will be returned. This is very efficient in 5250 applications, but less efficient with WebFacing.
is requested, SFLPAG rows will be returned. If the user performs a page down, then SFLPAG * 2
rows will be returned. This is very efficient in 5250 applications, but less efficient with WebFacing.
Since WebFacing is performance sensitive to the number of input/output fields that are requested from
WebFacing, the best option would be the first mode, since this will minimize the number of these fields
for each 5250 panel requested through WebFacing. The number of fields for a subfile is the number of
rows requested from the database (SFLSIZE) times the number of columns in each row.
WebFacing, the best option would be the first mode, since this will minimize the number of these fields
for each 5250 panel requested through WebFacing. The number of fields for a subfile is the number of
rows requested from the database (SFLSIZE) times the number of columns in each row.
Figure 6.7 shows a theoretical algorithm to graphically describe the effect the number of Input/Output
fields has on the performance of the WebFaced
application. The Y-axis metric is not important,
but merely can be used to measure the relative
amount of CPU horsepower that the application
needs to serve one single 5250 panel. In this
case, serving one single panel with 50 I/O fields
is approximately one half the CPU horsepower
needed to serve one 5250 panel with 350 I/O
fields. As you can see, the number of I/O fields
dramatically impacts the performance of your
WebFacing application, thereby reducing the I/O
fields will improve your performance.
fields has on the performance of the WebFaced
application. The Y-axis metric is not important,
but merely can be used to measure the relative
amount of CPU horsepower that the application
needs to serve one single 5250 panel. In this
case, serving one single panel with 50 I/O fields
is approximately one half the CPU horsepower
needed to serve one 5250 panel with 350 I/O
fields. As you can see, the number of I/O fields
dramatically impacts the performance of your
WebFacing application, thereby reducing the I/O
fields will improve your performance.
In our studies, we selected three customer
WebFaced applications, one simple, one
moderate, and one complex. See table 6.4, for
WebFaced applications, one simple, one
moderate, and one complex. See table 6.4, for
IBM i 6.1 Performance Capabilities Reference - January/April/October 2008
©
Copyright IBM Corp. 2008
Chapter 6 - Web Server and WebSphere
107
Figure 6.7 Shows the impact on CPU that the number of I/O
fields has per WebFaced panel
fields has per WebFaced panel
0
10
20
30
40
50
60
50
100
150
200
250
300
350
Average Num ber of Fields per Panel
Constant Overhead Per Panel
Overhead for I/O Fields