Edited wiki page Scaling through web user interface.

Scaling.wiki

diff --git a/Scaling.wiki b/Scaling.wiki
index 9f89770..bd0fc8c 100644
--- a/Scaling.wiki
+++ b/Scaling.wiki
@@ -4,15 +4,19 @@
 
 The first step to scaling is to scale your master server.  Some easy, but pricey ways to scale your master are:
 
-  * Adding cores, some of the larger installations use 24 core machines
-  * Adding RAM, most of the larger installations have at least 48GM, some have 100+GB
-  * Ensure fast disk IO, SSDs help
+  * Adding cores, some of the larger installations use 48 core machines
+  * Adding RAM, most of the larger installations have over 100GB, at least one has 1TB
+  * Ensure fast disk IO, SSDs help prevent serious performance degradation when repos are not well repacked.
   * Network, I suspect that most large installs use 10Gb ethernet
 
 = Mirrors/Slaves =
 
 Once you have a decent master, it is probably worth adding either some git mirrors (if you do not need ACLs on your repos), or Gerrit slaves to help offload much of your read only requests.  Mirrors/Slaves can also help reduce LAN and WAN traffic if you place them nearer your users/build hosts.  Some of the larger installations have at least 7 of these.
 
+== DB Slaves ==
+
+At least one site is using MYSQL replication for their slaves.  This can be particularly helpful to help reduce some WAN traffic related to high ref counts when doing repo syncs (the [https://gerrit-review.googlesource.com/#/c/35220 change cache] was designed to help with this.)
+
 = Multi - Master =
 
 Gerrit cannot yet be run in multi master mode, at least not the open source version.  The gerrit-review site does currently run in multi master mode, but it does not use the same code base as the open source version.  This however means that we are mostly aware of what it will take to make Gerrit support MultiMaster.  Any contributions in this direction should help make this a reality more quickly.
@@ -68,9 +72,6 @@
 
 High ref counts can have impacts in many places in the git/jgit/Gerrit stacks.  There are many ongoing fixes and tweaks to alleviated many of these problems, but some of them still remain.  Some can be "unofficially" worked around.
 
-== DB Slaves ==
-
-I am not aware of anyone using DB slaves yet, but it should help offload much of the WAN traffic to remote slaves.  This could be particularly helpful to help reduce some WAN traffic related to high ref counts.  A potential [https://gerrit-review.googlesource.com/#/c/35220 workaround].
 
 == git daemon mirrors ==