The transport channel services manage client connections and I/O
processing for HTTP and JMS requests. These I/O services are based on the
non-blocking I/O (NIO) features that are available in Java™. These
services provide a highly scalable foundation to WebSphere Application Server
request processing. Java NIO based architecture has limitations in terms of
performance, scalability and end user usability. Therefore, integration of
true asynchronous I/O is implemented. This implementation provides significant
benefits in usability, reduces the complexity of I/O processing and reduces
that amount of performance tuning you have to perform.
About this task
Key features of the new transport channel services include:
- Scalability, which enables the WebSphere Application Server to handle
many concurrent requests.
- Asynchronous request processing, which provides a many-to-one mapping
of client requests to Web container threads
- Resource sharing and segregation, which enables thread pools to be shared
between the Web container and a messaging service.
- Improved usability and
- Incorporation of autonomic tuning and configuration functions.
Changing the default values for settings on one or more of the transport
channels associated with a transport chain can improve the performance of
that chain.
Figure 1. Transport Channel Service
Procedure
- Adjust TCP transport channel settings. In the
administration console, click Servers > Application servers > server_name >
Ports. Then click View associated transports for the appropriate
port.
- Select the transport chain whose properties you are changing.
- Click on the TCP transport channel defined for that chain.
- Lower the value specified for the Maximum open connections property.
This parameter controls the maximum number of connections that are available
for a server to use. Leaving this parameter at the default value of 20000,
which is the maximum number of connections allowed, might lead to stalled
web sites under failure conditions, because the product continues to accept
connections, thereby increasing the connection, and associated work, backlog.
The default should be changed to a significantly lower number, such as 500,
and then additional tuning and testing should be performed to determine the
optimal value that you should specify for a specific Web site or application
deployment.
- If client connections are being closed without data being written
back to the client, change the value specified for the Inactivity timeout
parameter. This parameter controls the maximum number of connections
available for a server's use. Upon receiving a new connection, the TCP transport
channel waits for enough data to arrive to dispatch the connection to the
protocol specific channels above the TCP transport channel. If not enough
data is received during the time period specified for the Inactivity timeout
parameter, the TCP transport channel closes the connection.
The default
value for this parameter is 60 seconds, which is adequate for most applications.
You should increase the value specified for this parameter if your workload
involves a lot of connections and all of these connections can not be serviced
in 60 seconds.
- Adjust HTTP transport channel settings. In the
administration console, click Servers > Application servers > server_name >
Ports. Then click View associated transports for the appropriate
port.
- Select the transport chain whose properties you are changing.
- Click on the HTTP transport channel defined for that chain.
- Tune HTTP keep-alive. The Use persistent (keep-alive)
connections setting controls whether or not connections are left open between
requests. Leaving the connections open can save setup and teardown costs
of sockets if your workload has clients that send multiple requests. The default
value is true and is the optimal setting in most cases.
If your clients
only send single requests over substantially long periods of time, it is probably
better to disable this option and close the connections right away rather
than to have the HTTP transport channel setup the timeouts to close the connection
at some later time.
- Change the value specified for the Maximum persistent requests
parameter to increase the number of requests that can flow over a connection
before it is closed. When the Use persistent connections option
is enabled, the Maximum persistent requests parameter controls the number
of requests that can flow over a connection before it is closed. The default
value is 100. This value should be set to a value such that most, if not
all, clients always have an open connection when they make multiple requests
during the same session. A proper setting for this parameter helps to eliminate
unnecessary setting up and tearing down of sockets.
For test scenarios
in which the client will never close a socket or where sockets are always
proxy or Web servers in front of your application server, a value of -1 will
disable the processing which limits the number of requests over a single connection.
The persistent timeout will still shutdown some idle sockets and protect
your server from running out of open sockets.
- Change the value specified for the Persistent timeout parameter
to increase the length of time that a connection is held open before being
closed due to inactivity. The Persistent timeout parameter controls
the length of time that a connection is held open before being closed because
there is no activity on that connection. The default value is 30 seconds
This parameter should be set to a value that keeps enough connections open
so that most clients can obtain a connection available when they need to make
a request.
- If clients are having trouble completing a request because it
takes them more than 60 seconds to send their data, change the value specified
for the Read timeout parameter. Some clients pause more than 60
seconds while sending data as part of a request. To ensure they are able to
complete their requests, change the value specified for this parameter to
a length of time in seconds that is sufficient for the clients to complete
the transfer of data. Be careful when changing this value that you still protect
the server from clients who send incomplete data and thereby utilize resources
(sockets) for an excessive amount of time.
- If some of your clients require more than 60 seconds to receive
data being written to them, change the value specified for the Write timeout
parameter. Some clients are slow and require more than 60 seconds
to receive data that is sent to them. To ensure they are able to obtain all
of their data, change the value specified for this parameter to a length of
time in seconds that is sufficient for all of the data to be received. Be
careful when changing this value that you still protect the server from malicious
clients.
- Adjust Web container transport channel settings. In
the administration console, click Servers > Application servers > server_name >
Ports. Then click View associated transports for the appropriate
port.
- Select the transport chain whose properties need to be changed.
- Click on the Web container transport channel defined for that
chain.
- If multiple writes are required to handle responses to the client,
change the value specified for the Write buffer size parameter to a value
that is more appropriate for your clients. The Write buffer size
parameter controls the maximum amount of data per thread that the Web container
buffers before sending the request on for processing. The default value is
32768 bytes, which is sufficient for most applications. If the size of a
response is greater than the size of the write buffer, the response is chunked
and written back in multiple TCP writes.
If you need to change the value
specified for this parameter, make sure the new value enables most requests
to be written out in a single write. To determined an appropriate value for
this parameter, look at the size of the pages that are returned and add some
additional bytes to account for the HTTP headers.
- Click Apply and then Save to save these changes.