It is tempting to assume that clustering CQ is a way to increase performance, however it is important to understand that the performance improvements from clustering are generally very limited. Clustering does not scale any sort of write or update activity within CQ, as all writes have to occur at the cluster master node and are processed nearly synchronously. Moreover handling writes requires locking between nodes that excludes concurrent reads. The net result is that:
- Clusters scale somewhat for exclusively read-only applications, but no better than non-clustered farms
- Clusters scale only marginally, if at all, when any updates are present. 1% (one update in 100 page hits) is enough to spoil the scalability of a cluster
- Clusters of more than three nodes may actually scale negatively in performance, if substantial (>2%) writes are necessary
In general, clusters of two nodes are recommended, versus any other cluster topology. Clusters are recommended for the purpose of reliability/redundancy rather than as a performance or scalability measure. In a two-node cluster, it is generally recommended that the application traffic be directed to the master node exclusively, with the slave held as a standby in the event of a failure -- an "active/standby" arrangement -- with the expectation that the overall system performance/throughput is about the same as a single node.
