anchor.diff:  the technology in use. Router performance might be limited by the
   capabilities and performance of the applications behind it, such as language or
   static versus dynamic content.
  -////
   
   Router sharding should be used to serve more routes towards applications and
   help horizontally scale the routing tier.
  
positive.code: 
  * underlying infrastructure (network/SDN solution, CPU, and so on)
  
  ////
  COMMENTING OUT METRICS UNTIL WE GET NEW DATA
  While performance in your specific environment will vary, Red Hat lab
  tests on a public cloud instance of size 4 vCPU/16GB RAM, a single
  HAProxy router handling 100 routes terminated by backends serving
  
negative.code: 
  [cols="3",options="header"]
  |===
  |*Encryption* |*LoadBalancerService*|*HostNetwork*
  |none |21515|29622
  |edge |16743|22913
  |passthrough |36786|53295
  |re-encrypt |21583|25198
  |===
  
  In HTTP close (no keep-alive) scenarios:
  
  [cols="3",options="header"]
  |===
  |*Encryption* |*LoadBalancerService*|*HostNetwork*
  |none |5719|8273
  |edge |2729|4069
  |passthrough |4121|5344
  |re-encrypt |2320|2941
  |===
  
  Default router configuration with `ROUTER_THREADS=4` was used and two
  different endpoint publishing strategies (LoadBalancerService/HostNetwork) tested.
  TLS session resumption was used for encrypted routes. With HTTP
  keep-alive, a single HAProxy router is capable of saturating 1 Gbit
  NIC at page sizes as small as 8 kB.
  