Bug 1263396 - [RFE] Apply changes required to use Vert.x cartridge in OpenShift Online
Summary: [RFE] Apply changes required to use Vert.x cartridge in OpenShift Online
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: OpenShift Online
Classification: Red Hat
Component: Image
Version: 2.x
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: ---
: ---
Assignee: John Goulding
QA Contact: DeShuai Ma
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-09-15 18:16 UTC by Ricardo Martinelli de Oliveira
Modified: 2019-08-15 05:25 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-05-31 18:22:11 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Ricardo Martinelli de Oliveira 2015-09-15 18:16:19 UTC
Description of problem:

Customer have deployed a Http scaling Server using Vertx Cartridge in a Medium size gear:
https://marketplace.openshift.com/apps/10366?restoreSearch=true#!features

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:
http://vertx.io/vertx2/manual.html#performance-tuning

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 17:24:19 UTC
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 19:49:35 UTC
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 18:22:11 UTC
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.