This topic provides quick links to information about tuning specific WebSphere® application types, and the services and containers that support them.
Application serving environment -- See Tuning the application serving environment | WebSphere applications | WebSphere applications |
---|---|---|
Servers
The product subsystems are discussed in the Product architecture. For the most part, they do not depend on the type of applications being deployed |
Services
J2EE applications
|
J2EE resources
|
WebSphere for WebSphere Application Server for z/OS gives you the ability to install your application either in a single server or spread it across multiple servers. There are many reasons for partitioning your application. However, for performance, placing your application all in the same server will always provide better performance than partitioning it. If you do choose to partition your application across servers, you will get better performance if there are at least replica servers on each system in the sysplex. The WebSphere for WebSphere Application Server for z/OS runtime will try to keep calls local to the system if it can, which will, for example, use local interprocess calls rather than sockets.
You also have a choice of running server regions with an isolation policy of one tran per server region or multiple trans per server region. From a performance perspective, running more threads in a server region will consume less memory but at the cost of thread contention. This contention is application-dependent. We generally recommend the use of multiple trans unless you run into contention problems.
On a local client, the client and the optimized communication are done on the same system. This has some additional client CPU costs but less communication cost. On a remote client, the client cost is replaced by the additional communication overhead of sockets. The CPU cost on either system is almost equivalent. Latency is better for a local client than for a remote client, meaning you will get better response time with a local client.
You can define more than one copy of a server on a system. These copies are called clones. We have found slight improvements in performance when running with a couple of clones as opposed to just one (very large configuration). While there is some benefit, IBM® does not recommend, at this time, the creation of replicated control regions for the sole purpose of improving performance. We do, however, recommend them for eliminating a single point of failure and for handling rolling upgrades without introducing an outage.