Performance

First, a threaded Web server is preferred over a strictly process-based Web server for two reasons:

1. Since there is a separate instance of the ESI processor's cache for each process, a threaded Web server with fewer processes allows a higher degree of cache sharing, and thus a higher cache hit ratio, lower memory consumption, and increased performance.

2. If ESIInvalidationMonitor is set to true (that is, if invalidations flow back to the ESI processor), then a long-running connection is maintained from each process to the ESIInvalidatorServlet in each appserver cluster. Furthermore, each of these connections uses a thread in the application server to manage the connection. Therefore, a threaded Web server uses far fewer connections to the back-end application server, and far fewer threads to manage these connections.

Warning: It was noted from our testing of Trade3 on Red Hat Linux Advanced Server 2.1 that more than 100 threads per process had adverse affects. In particular, the cost of using pthread_mutex locks (as is used by the ESI processor) with a large number of threads introduced a CPU bottleneck. By configuring IHS 2.0 to have 100 threads per process, pthread_mutex contention was minimized and the CPU utilization was maximized. The optimal thread-to-process ratio may differ for your application and will depend upon the cost of computing the data to be cached.

Figure 14-41 shows a performance comparison of Trade3 on Windows with:

No caching

Servlet and command caching, but no ESI caching

Servlet, command, and ESI caching

Figure 14-41 Benefits of caching

Figure 14-41 shows that servlet and command caching boost performance approximately 250%. ESI boosts the performance another 38% with a 90% read-to-update ratio for Trade3.

  Prev | Home | Next

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.