IBM SG24-6526-00 Benutzerhandbuch
Chapter 5. Performance tuning
123
5.3.2 Stateless connections
The majority of call.connect beans and all vendor.connect beans are common stateless
session beans and use stateless connections. One method call (typically one interaction
between the client and the server) obtains a stateless connection from the WebSphere
datasource, performs the necessary work, and then returns the connection to the pool.
session beans and use stateless connections. One method call (typically one interaction
between the client and the server) obtains a stateless connection from the WebSphere
datasource, performs the necessary work, and then returns the connection to the pool.
If all clients would execute a method at exactly the same time, then you would need one
connection per client. A single call.connect client sometimes obtains two independent
connections for reasons of transaction boundaries.
connection per client. A single call.connect client sometimes obtains two independent
connections for reasons of transaction boundaries.
In an extreme case, the number of stateless connections required could be twice the number
of clients. However in practice, this is extremely unlikely. You should attempt to estimate the
likely number of simultaneous connections. Once the system is running, you can verify your
estimate with the WebSphere Resource Analyzer. If your value is too low, then clients will
have to wait for connections and response times may become unpredictable. If the value is
too high, then you will use more iSeries resources than required. If you are in doubt, err on
the high side, a small number of active but idle connections is unlikely to be a problem.
of clients. However in practice, this is extremely unlikely. You should attempt to estimate the
likely number of simultaneous connections. Once the system is running, you can verify your
estimate with the WebSphere Resource Analyzer. If your value is too low, then clients will
have to wait for connections and response times may become unpredictable. If the value is
too high, then you will use more iSeries resources than required. If you are in doubt, err on
the high side, a small number of active but idle connections is unlikely to be a problem.
If call.connect and vendor.connect are on the same iSeries, then you can configure them to
use separate datasources or a common one. The pros and cons of the choice are complex. A
common source may reduce the number of connections required since it is unlikely that both
applications will reach their maximum usage levels at the same time. On the other hand,
sharing the connections means that all connections accumulate prepared statements from
each application. Therefore, they have a larger memory requirement per connection than if
they were separated. A simple setup uses a common pool. Unless you have a reason to do
otherwise, you should retain this.
use separate datasources or a common one. The pros and cons of the choice are complex. A
common source may reduce the number of connections required since it is unlikely that both
applications will reach their maximum usage levels at the same time. On the other hand,
sharing the connections means that all connections accumulate prepared statements from
each application. Therefore, they have a larger memory requirement per connection than if
they were separated. A simple setup uses a common pool. Unless you have a reason to do
otherwise, you should retain this.
The size of the datasource connection pool can be controlled using the WebSphere console.
Start the console and select the datasource used by your application. On the WebSphere
Console’s DataSource panel (Figure 5-17), select the Advanced tab. Note the Minimum
connection pool size and the Maximum connection pool size fields.
Start the console and select the datasource used by your application. On the WebSphere
Console’s DataSource panel (Figure 5-17), select the Advanced tab. Note the Minimum
connection pool size and the Maximum connection pool size fields.
The maximum pool size has the most significant affect on performance. If it is insufficient,
then clients are forced to wait when they need a connection. In extreme cases, the application
can lock up. The ideal tuning technique is to use the WebSphere Resource Analyzer to
monitor actual use. A simpler approach is to make a high estimate and drop it down gradually
until it impacts performance. Except for extreme values, performance is not greatly affected
by this setting.
then clients are forced to wait when they need a connection. In extreme cases, the application
can lock up. The ideal tuning technique is to use the WebSphere Resource Analyzer to
monitor actual use. A simpler approach is to make a high estimate and drop it down gradually
until it impacts performance. Except for extreme values, performance is not greatly affected
by this setting.
The minimum pool size is less significant but worth considering. This is the number of
connections that WebSphere will retain even if they are not in use. The default of 1 is
reasonable if there are extended periods in which WebSphere is not in use but other
applications are. However, if there will rarely be times when WebSphere is idle, or when
WebSphere and most other applications are idle, then a larger value is desirable. Larger
values should improve startup times after periods of inactivity. Try to estimate the lowest level
of WebSphere usage while other applications are busy. Ignore periods when WebSphere and
other applications are not busy.
connections that WebSphere will retain even if they are not in use. The default of 1 is
reasonable if there are extended periods in which WebSphere is not in use but other
applications are. However, if there will rarely be times when WebSphere is idle, or when
WebSphere and most other applications are idle, then a larger value is desirable. Larger
values should improve startup times after periods of inactivity. Try to estimate the lowest level
of WebSphere usage while other applications are busy. Ignore periods when WebSphere and
other applications are not busy.