<commit_before>[id="baseline-router-performance-{context}"]
= Baseline router performance

The {product-title} router is the ingress point for all external traffic
destined for {product-title} services.

When evaluating a single HAProxy router performance in terms of
HTTP requests handled per second, the performance varies depending
on many factors. In particular:

* HTTP keep-alive/close mode

* route type

* TLS session resumption client support

* number of concurrent connections per target route

* number of target routes

* back end server page size

* 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
1kB static pages is able to handle the following number of transactions
per second.

In HTTP keep-alive mode scenarios:

[cols="3",options="header"]
|===
|*Encryption* |*ROUTER_THREADS unset*|*ROUTER_THREADS=4*
|none |23681|24327
|edge |14981|22768
|passthrough |34358|34331
|re-encrypt |13288|24605
|===

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
|===

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.

When running on bare metal with modern processors, you can expect roughly
twice the performance of the public cloud instance above. This
overhead is introduced by the virtualization layer in place on public clouds and
holds mostly true for private cloud-based virtualization as well. The following
table is a guide on how many applications to use behind the router:

[cols="2,4",options="header"]
|===
|*Number of applications* |*Application type*
|5-10 |static file/web server or caching proxy
|100-1000 |applications generating dynamic content

|===

In general, HAProxy can support routes for 5 to 1000 applications, depending on
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.<commit_msg>Updating baseline OCP router performance numbers for 4.1<commit_after>[id="baseline-router-performance-{context}"]
= Baseline router performance

The {product-title} router is the ingress point for all external traffic
destined for {product-title} services.

When evaluating a single HAProxy router performance in terms of
HTTP requests handled per second, the performance varies depending
on many factors. In particular:

* HTTP keep-alive/close mode

* route type

* TLS session resumption client support

* number of concurrent connections per target route

* number of target routes

* back end server page size

* underlying infrastructure (network/SDN solution, CPU, and so on)

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
1kB static pages is able to handle the following number of transactions
per second.

In HTTP keep-alive mode scenarios:

[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.

When running on bare metal with modern processors, you can expect roughly
twice the performance of the public cloud instance above. This
overhead is introduced by the virtualization layer in place on public clouds and
holds mostly true for private cloud-based virtualization as well. The following
table is a guide on how many applications to use behind the router:

[cols="2,4",options="header"]
|===
|*Number of applications* |*Application type*
|5-10 |static file/web server or caching proxy
|100-1000 |applications generating dynamic content

|===

In general, HAProxy can support routes for 5 to 1000 applications, depending on
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.
{'fraction_non_alphanumeric': 0.06995169082125603, 'fraction_numerical': 0.03961352657004831, 'mean_word_length': 5.374384236453202, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5701667', 'n_tokens_mistral': 1537, 'n_tokens_neox': 1382, 'n_words': 675}