WebSphere queuing network

The IBM WebSphere Application Server Tuning Guide describes transactions to WebSphere® as being processed in a network of interconnected queues that includes the network, Web Server, Web Container, EJB container, data source, connection pool, and the database sessions.

IBM® then recommends that the queues closest to the client be large (e.g., the network) and that downstream queues (e.g., EJB container, data source) grow progressively smaller as it gets further from the client. One of the reasons offered is that an application that spends 90% of its time in a complex servlet and only 10% of its time making short JDBC queries would require a significantly smaller database connection queue than the Web Container queue.

We agree with the first statement that the network queue can be large because it is preferable to queue in the network and not in the application server. However, from our experience, the downstream queues should be set to the same size if not larger.

In database-intensive applications, such as Sterling Selling and Fulfillment Foundation, when a transaction enters the Web Container, the APIs almost always require a database connection. If one were to allow 20 concurrent transactions (by setting Maximum Thread Size in the Web Container Services) to run against a connection pool of 12, there is a possibility that at peak processing periods, 8 transactions would either be forced to wait for a connection or throw an exception because it can't get a connection.

Using the same argument, the database instance should be able to create more sessions than the sum of all the connections possible from all the WebSphere instances combined. You also need additional database sessions for standalone Java™ applications that need database services (for example, the Sterling Selling and Fulfillment Foundation agents or monitors), real-time performance monitors, database utilities and so forth.