anchor.diff:  
   [cols="3",options="header"]
   |===
  -|*Encryption* |*ROUTER_THREADS unset*|*ROUTER_THREADS=4*
  -|none |23681|24327
  -|edge |14981|22768
  -|passthrough |34358|34331
  -|re-encrypt |13288|24605
  +|*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* |*ROUTER_THREADS unset*|*ROUTER_THREADS=4*
  -|none |3245|4527
  -|edge |1910|3043
  -|passthrough |3408|3922
  -|re-encrypt |1333|2239
  +|*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.
  
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: 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.
  