The transport channel services manage client connections and I/O
processing for HTTP and JMS requests. These new I/O services are based on
new non-blocking I/O features available in Java™. These services provide a highly scalable
foundation to WebSphere Application Server request processing.
Why and when to perform 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 TCP,
HTTP, or Web container transport channels associated with a transport chain
can improve the performance of that chain.
Figure 1. Transport Channel
Service
Steps for this task (dependent on configuration)
- 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.
- Leave the Maximum open connections parameter set to the default
value. This parameter controls the maximum number of connections
that are available for a server's use. It should be left at the default value
of 20000, which is the maximum number of connections allowed. The transport
channel service by default manages high client connection counts and requires
no tuning.
- 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.
- Assign a thread pool
to a specific HTTP port. Each TCP transport channel is assigned
to a particular thread pool. Thread pools can be shared between one or more
TCP transport channels as well as with other components. The default settings
for a TCP transport channel is to have all HTTP based traffic assigned to
the WebContainer thread pool and all other traffic assigned to the Default thread
pool. Use the Thread pool pull-down to assign a particular thread pool to
each TCP transport channel. The default settings for this parameter has all
HTTP based traffic assigned to the WebContainer thread pool and all
other traffic is assigned to the Default thread pool. (Thread pool collection describes how to create additional thread pools.)
- Tune the size of your thread pools.
By default, a thread pool can have a minimum of 10 threads and a maximum
of 50 maximum threads. To adjust these values, click on Thread pools > threadpool_name and
adjust the values specified for the Minimum Size and Maximum Size parameters
for that thread pool.
Typical applications usually do not need more than
10 threads per processor. One exception is if there is some off server condition,
such as a very slow backend request, that causes a server thread to wait for
the backend request to complete. In such a case, CPU usage is usually low
and increasing the workload does not increase CPU throughput. Thread dumps
show nearly all threads in a call out to the backend resource. If this condition
exists, and the backend is tuned correctly, try increasing the minimum number
of threads in the pooll until you see improvements in throughput and thread
dumps show threads in other areas of the runtime besides the backend call.
The
setting for the Grow as needed parameter should not be changed unless your
backend is prone to hanging for long periods of time. This condition might
indicate that all of your runtime threads are blocked waiting for the backend
instead of processing other work that does not involve the hung backend.
- 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 (keep-alive) 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 you are changing.
- 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 will be 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.