JEE: Server Performance and Configuration
Guest Post by
Anupindi Ravi Shankar, Technology Architect, Manufacturing, Infosys Limited
An often heard complaint from development managers is
"The response time of our web application is very high to pass the UAT.What corrective steps can we take to improve the performance of our application?"
Such statements are a clear indication of the fact that either the performance aspect was not considered or even if considered during requirements, architecture or design stages, was not executed fully. In most of the cases, performance aspect is being side-tracked for functional features and is considered only in the eleventh hour when the performance improvements prove very expensive and often patch works or quick workarounds are done to make the application perform better
We should not attribute performance issues totally on the development. I would say that the development considerations amount to just 30-40% in the entire performance life cycle of the application.
The non functional considerations like user base, data volume, availability etc along with the network topology layout, appropriate capacity planning exercise, accurate server configurations, development considerations, load and performance testing together form the areas which need to be looked into, from a performance perspective. Whatever encompasses our network boundary should be considered.
Having worked on Performance Engineering exercise for quite some time, I would like to discuss on the performance aspects which can/should be considered at the server configuration level. The below diagram shows a typical deployment view of a web application designed for High Availability, failover support, security and performance.
Fig1: Illustrative Deployment View of the Web Application
This blog and the following ones will talk about configurations for each of the IBM servers (left to right) as shown in the above deployment diagram. There could be same/similar configuration settings for non-IBM servers also.
Let's start with the configuration settings for WebSEAL server (6.x) which can be considered for performance improvement. When we applied these settings in one of our projects we found a significant improvement in the response time of the page. So before we start with the configuration settings, let's quickly cover on what a WebSEAL server is. Going by the Internet definition of WebSEAL it is a reverse proxy server which is used to serve the requests by delivering content from its own web server or from the junctioned backend server. Apart from this, it is also used for SSO, Authentication and Authorization empowered by Tivoli Access Manager (TAM).
WebSEAL Configuration Settings for Performance
Following are some of the configuration settings which can be considered.
- HTTP Logging
- Static Content Caching
- HTTP Data Compression
- Worker Thread Settings
The below section describes each of these settings in detail.
|
Property Name |
Default Value |
Value for consideration |
Remarks |
|
HTTP Logging WebSEAL maintains three conventional HTTP log files that record activity rather than messages
|
Enabled |
Disable [logging]
|
Logging can be a performance overhead and can be disabled |
You define HTTP logging in the [logging] stanza of the webseald.conf configuration file, which can be located at
|
Environment |
Path |
|
Windows |
pd_install_dir\etc\webseald.conf |
|
UNIX |
/opt/pdweb/etc/webseald.conf |
I am not giving details of log files and the information they contain. To get a detailed understanding of these log files please refer WebSEAL admin guide
|
Property Name |
Default Value |
Value for consideration |
Remarks |
|
Static content Caching · Allows document to be served locally rather than junctioned servers. · Static text documents (html, CSS, JS) and images files can be served from server memory, thereby providing faster response to follow-up requests for documents. |
No Cache |
Cache the static content. Specify MIME type, Cache-type and Cache size mime-type> =<cache-type>:<cache-size> |
Improved response time for the web page. |
You define Web document caching in the [content-cache] stanza of the webseald.conf configuration file.
Example:
[content-cache]
Text/html = memory: 2500
Image/* = memory: 3000
|
Property Name |
Default Value |
Value for consideration |
Remarks |
|
HTTP Data Compression · Allows compressed data to be transferred over HTTP between the WebSEAL server and the client. · Data can be compressed based on MIME types, browser type and Protected Object Policies |
Not Specified |
[compress-mime-types] mime_type = minimum_doc_size [:compression_level] minimum_doc_size values : -1,0,>0 compression_level values : 1-9 |
Improved response time for the web page. |
Example:
[compress-mime-types]
Image/* = 0 : Compress all Images
Text/css = -1 : Disable compression of CSS files
Text/html = 2000 : Compress HTML files of size > 2000 bytes
To get a detailed understanding of supported file compression techniques please refer WebSEAL infocenter
Worker Thread Settings
|
Property Name |
Default Value |
Value for consideration |
Remarks |
|
Worker Thread Settings · Allows incoming requests to be handled by the WebSEAL |
50 |
[server] worker-threads = 50 Worker threads can be configured at global level as well as per-junction level. For Global level adjust these values.
Per junction values can be set like this
|
Process memory usage limits must be properly adjusted |
To get a detailed understanding of worker thread settings please refer to WebSEAL infocenter
I hope these WebSEAL configurations will come in handy when you are working on performance engineering for your Web Application. Do share with me your experience after using them.
In the next one, I will talk about performance configuration settings for IBM HTTP server.
