Customers need to know what kind of performance to expect from Geo. This depends on innumerable factors. We can set expectations by defining and benchmarking "Geo Reference Architectures". For example, a particular Geo reference architecture may specify: * 1 primary 10k ref arch in GCP `us-east4-c` * Seeds: * 1000 deterministically generated project repos with defined stats (size, number of files, file size) * Etc, other file types * Add 1 secondary 5k ref arch in GCP `europe-west9-c` with Unified URL Metrics to gather: * Run GPT from `us-east4-c` and `europe-west9-c` before adding secondary * Run GPT from `us-east4-c` and `europe-west9-c` during backfill * Run GPT from `us-east4-c` and `europe-west9-c` after backfill * Time for PG replication to "finish" (< 10s lag) * Time to backfill (all resources synced successfully at least once) * Time to replicate a new huge Git repo * Time to replicate a new huge LFS file * Enhance GPT with secondary site measurements during load * Take a measurement of bandwidth between sites * Address RPO/RTO expectations? * ?? The above is maybe weight 5 by itself, and it needs to be repeated with permutations of reference architectures, seeds, and regions, and later, GitLab versions. So it must be mostly automated. If we produce decent tooling, it may also be valuable for customer POCs.