Web applications in a clustered deployment can provide better performance since multiple machines can handle more load than one. Clusters also provide high availability: if one machine goes off-line, clients can connect to another server in the cluster. To run your Web application in a cluster, you must configure a mechanism to support load balancing of HTTP requests, and optionally failover. For more information, see “Deploying Web applications to a cluster” in Chapter 7, “Load Balancing, Failover, and Component Availability,” in the EAServer System Administration Guide.
Chapter 5, “Web Application Tuning,” describes the Web application settings that you can tune for single-server deployments. In a clustered deployment, these additional settings affect performance:
Your choice of session replication options
The cache size, if replicating sessions in memory
In a clustered deployment, EAServer replicates user session data stored in HTTP sessions so that the same data is available on other servers in the cluster. Replication can use a remote database server or in-memory storage.
If using in-memory replication, EAServer replicates data between mirror pairs, that is, a pair of servers configured to share the same user session. In-memory replication can perform better than using a database, but requires more memory on each server. Specify a cache size to constrain the memory required by the cache, and specify a timeout to free up memory used by idle sessions. To set these parameters, follow the instructions in “Deploying Web applications to a cluster” in Chapter 7, “Load Balancing, Failover, and Component Availability,” in the EAServer System Administration Guide.
If using database replication, all servers in the cluster store session data in a remote database. This mechanism can perform slower than in-memory replication, but requires less memory. Also, EAServer can share a client’s session data on more than two servers. If using this technique:
Tune the connection cache settings as described in “Connection cache settings”.
Make sure the table used is indexed. For information on creating the database table, see “Table schema for binary storage” in Chapter 29, “Configuring Persistence Mechanisms,” in the EAServer Programmer’s Guide.
In the default configuration, EAServer validates a client’s HTTP session during each request. In a clustered deployment, session validation is more resource intensive since EAServer stores the session in a database or using a replicated cache. If you enable lazy validation, EAServer validates the session only when a servlet or JSP calls ServletRequest.getSession() or ServletRequest.getSession(boolean). To enable this setting, set the com.sybase.jaguar.webapplication.lazydistributedhttpsessionvalidation Web application property to true.
Lazy validation can improve performance. However, enabling lazy authentication has the following side effects:
The last-accessed-time session attribute is set only when the servlet or JSP accesses the session. Consequently, the session may expire sooner than expected if the client accesses only static pages or servlets and JSPs that do not access the session data.
When the session is invalidated, the client is not assigned a new session until they request a page that requires a session.
The client’s security credentials (if any) are available only to JSPs and servlets that are marked protected via the security constraints property. Other pages cannot retrieve the client’s credentials—the ServletRequest.getUserPrincipal() method returns null even though the client is logged in.
| Copyright © 2005. Sybase Inc. All rights reserved. |
|
|