Scaling and Performance Plan

Written By: David E. Jones

Web Load Handling Tiers

Web, or HTTP, based traffic can be load balanced and accelerated at different points between the user and the database.  This is a list of the main touch points, some of which are optional.

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 area distributed server farms where a user is automatically forwarded to the nearest (fastest) farm. Today this role is most commonly filled by a CDN (e.g. Cloudflare, Fastly, Amazon CloudFront), which also handles static asset caching and TLS termination at the edge.
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. This category today is generally covered by application delivery controllers (e.g. NetScaler/Citrix ADC, F5 BIG-IP) or a cloud provider's own load balancer (AWS ALB/NLB, GCP Load Balancing, Azure Load Balancer)
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: AJP13 (maintained connection), JNI (fast direct calls), LB (load balancing) (see the mod_jk and workers howtos for more information). AJP12 (the older ad-hoc connection protocol) has since been removed from Tomcat and is no longer an option.
   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. Managed cloud database services (e.g. Amazon RDS/Aurora, Google Cloud SQL, Azure Database) provide this largely out of the box via read replicas and automated failover
   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
      
      Note: if you run multiple OFBiz instances against one shared database, also see Load Balancing and Clustering Multiple OFBiz Instances for OFBiz's own distributed-cache-clear-enabled mechanism, which keeps each instance's in-memory entity caches consistent with the others.

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 this is a large data set that is read frequently and cannot fit into a memory cache, but can be copied into multiple read-only databases (i.e. read replicas). For write-heavy applications, multiple transaction-oriented databases can be set up to support data gathering, with the data later consolidated in a data warehouse for analysis, reporting, etc.

Performance Trade-Offs

Scalability vs. Performance

Components are designed with scalability, or the support of many users, in mind. Where options are available to implement a procedure or data structure to support high performance or scalability, scalability is chosen even if performance is negatively affected. However, if no real scalability issues get in the way, performance is optimized as much as is needed for the application.

Maintainability vs. Performance

Sometimes design choices for procedures and data structures can emphasize maintainability or performance, but do not support both well and so present a trade-off situation. In these cases maintainability, or customizability, is the most important factor. In cases where a certain design causes an unreasonable decrease in performance, or where timing constraints are not being met, optimization may be done after the fact to tune the application, minimizing as much as possible the decrease in maintainability and customizability.