Bug 1263396 - [RFE] Apply changes required to use Vert.x cartridge in OpenShift Online
[RFE] Apply changes required to use Vert.x cartridge in OpenShift Online
Product: OpenShift Online
Classification: Red Hat
Component: Image (Show other bugs)
Unspecified Unspecified
low Severity low
: ---
: ---
Assigned To: John Goulding
DeShuai Ma
Depends On:
  Show dependency treegraph
Reported: 2015-09-15 14:16 EDT by Ricardo Martinelli de Oliveira
Modified: 2017-05-31 14:22 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-05-31 14:22:11 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ricardo Martinelli de Oliveira 2015-09-15 14:16:19 EDT
Description of problem:

Customer have deployed a Http scaling Server using Vertx Cartridge in a Medium size gear:

They tested it using Apache Bench but it seems to have issue when trying more than 1000 concurrent users from Apache Bench (Failed requests, Connection reset by peer(104)) and it never scales with high demand.

The Vertx Documentation include some tips for performance tuning on the server running Vertx:

However, some of these tips need to be done with super user privileges, specifically:
sudo sysctl -w net.core.somaxconn=10000
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=10000

So customer is requesting if it is possible apply this change in Online environment.
Comment 1 Andy Grimm 2015-09-21 13:24:19 EDT
I'm taking this one, because this setting is fairly sensitive to node size, gear limits per node, etc., and the request is specifically for OpenShift Online.
Comment 2 Andy Grimm 2015-09-21 15:49:35 EDT
As the Vertx documentation states: "10000 is an arbitrarily large number".  I have spoken to our performance engineers, and we will experiment with increasing these values, but we will increase them gradually, and these are not a magic bullet.  There are several other potential bottlenecks, and somaxconn and tcp_max_syn_backlog are just two of the first ones.  After the connection is accepted and the SYN is ACKed, the request still has to be handled by the frontend web proxy before reaching the gear's web server, so it's very possible that this will just move the connection refusal from the kernel to the proxy.
Comment 9 Eric Paris 2017-05-31 14:22:11 EDT
We apologize, however, we do not plan to address this report at this time. The majority of our active development is for the v3 version of OpenShift. If you would like for Red Hat to reconsider this decision, please reach out to your support representative. We are very sorry for any inconvenience this may cause.

Note You need to log in before you can comment on or make changes to this bug.