-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Increased the time the proxy will hold connections when unidling #12754
Increased the time the proxy will hold connections when unidling #12754
Conversation
@openshift/networking PTAL |
What user is going to wait for 120 seconds? |
I would never wait for 30 seconds for anything. |
We chose 30s as the longest possible value a user would wait. I'd argue the problem here is not idling - it's the rest of the system sucks. As a user, I don't care that our image pulls are slow - I expect it to just work. |
So is the real problem here the quick-start applications that have the 30 second delay before the readiness checks? |
I don't disagree that waiting for 30 seconds is awful, but what's the cost in making the system wait that long, allowing patient users (or programs that are connecting) to wait longer rather than dropping them on the floor at 30 seconds? |
One angle here is that event delivery isn't guaranteed - unidling is best effort. So if the event misses, that's 4 times longer that it would be before someone hit refresh and tried to unidle. |
How about this - I'm not opposed to making this configurable. I'm much less certain that a longer default makes anything work better (quickstarts that don't start in 30seconds aren't very quick). Heroku for instance comes up in under 3-5 seconds. That's really the experience we're looking for, and I would at least put pressure on the other parts of the product to not suck. |
I'm ok with bumping the timeout to 120s if we promise to make this configurable ASAP |
[test] |
Before we would wait 30 seconds for a pod to come live before dropping the connections. That time is too short, so we have increased it to 120 seconds. Fixes bug 1416037 (https://bugzilla.redhat.com/show_bug.cgi?id=1416037)
461cfcf
to
845e285
Compare
Evaluated for origin test up to 845e285 |
continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/13523/) (Base Commit: 89ed457) |
Created trello card https://trello.com/c/W3PYdBDG to do the settings work @smarterclayton requested. [merge] |
Evaluated for origin merge up to 845e285 |
This will probably also fix #10773 |
continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/13549/) (Base Commit: f6d6014) (Image: devenv-rhel7_5842) |
Before we would wait 30 seconds for a pod to come live before dropping
the connections. That time is too short, so we have increased it to
120 seconds.
Fixes bug 1416037 (https://bugzilla.redhat.com/show_bug.cgi?id=1416037)