Page History

...

1. HTML Client
   1. Pages and images are often cached on the client; for dynamic pages this may be good to turn off so that the user always gets the freshest version from the server
   2. Simple fail-over can be done on this level manually by giving the user multiple URLs for the application (not a common approach, and only applicable for internal or back-office applications)
2. Edge Router (optional)
   1. An edge router allows for wide are distributed server farms where a user is automatically forwarded to the nearest (fastest) farm
3. IP Accelerator (optional)
   1. Sits in front of an HTTP or other server and handles IP connections for the server, maintaining a single connection to the server
   2. Some IP accelerators can be clustered for load balancing on this level and for high availability
   3. Some can load balance over multiple HTTP servers
   4. Some vendors that do this include: www.alacritech.com, www.netscaler.com, www.packeteer.com, www.redlinenetworks.com
4. HTTP Server - Apache (optional)
   1. Can be skipped by setting up Tomcat to listen on the desired port
   2. Has plugins to support connection to Tomcat: AJP12 (ad-hoc connection), AJP13 (maintained connection), JNI (fast direct calls), LB (load balancing) (see the mod_jk and workers howtos for more information)
   3. Plugin can support load balancing among multiple Tomcat servers, many Tomcat instances to one Apache instance and one site
   4. Plugin can also support multiple virtual hosted sites targeting different Tomcat servers, many Tomcat instances to one Apache instance and many sites
5. Servlet Engine - Tomcat
   1. Many Tomcat instances to one database instance (or pool) is easy because database clients are made to be distributed and can be called from anywhere
   2. Data from the database can be cached at this level for highest speed but least shared read access (the best to cache is data that is read a lot, infrequently changed, and that is not sensitive to being stale or out of date)
6. RDBMS
   1. Some databases support clustering, data synchronization and failover, these are most commonly used in larger deployments as database servers tend to be stable
   2. Different database tables can be stored on different machines; for example the catalog on one database server and the user information on another and logging information on another

Custom Performance Enhancements

In some cases scaling with standard hardware and software patterns is not sufficient or cost effective, but the applications are well suited to custom performance enhancements. An example of these are larger data sets are read frequently and that cannot fit into a memory cache, but can be copied into multiple read-only databases. For write heavy applications multiple transaction-oriented databases can be setup to support data gathering and then the data can be consolidated in a warehouse for analysis, reporting, etc.

Performance Trade-Offs

Scalability vs. Performance

...