Skip to content
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

feat(chain): use nextTick instead of setImmediate #1808

Merged
merged 1 commit into from Dec 2, 2019

Conversation

mmarchini
Copy link
Contributor

@mmarchini mmarchini commented Nov 25, 2019

BREAKING CHANGE: Using setImmediate has more overhead than nextTick on
Node.js v12. Benchmarks show improvements of >20% when changing
setImmediate to nextTick:

  response-json throughput:
  {
      "significant": "***",
      "equal": false,
      "wins": "head",
      "diff": "28.62%"
  }

  ---- response-text ----
  ✔ Results saved for head/response-text
  ✔ Results saved for stable/response-text
  response-text throughput:
  {
      "significant": "***",
      "equal": false,
      "wins": "head",
      "diff": "43.45%"
  }

  ---- router-heavy ----
  ✔ Results saved for head/router-heavy
  ✔ Results saved for stable/router-heavy
  router-heavy throughput:
  {
      "significant": "***",
      "equal": false,
      "wins": "head",
      "diff": "30.02%"
  }

  ---- middleware ----
  ✔ Results saved for head/middleware
  ✔ Results saved for stable/middleware
  middleware throughput:
  {
      "significant": "***",
      "equal": false,
      "wins": "head",
      "diff": "20.78%"
  }

This changes the order some events are processed (nextTick is processed
earlier than setImmediate), thus this can be considered a breaking
change as some edge cases will notice this (as we can see in the test
changes).

Pre-Submission Checklist

  • Opened an issue discussing these changes before opening the PR
  • Ran the linter and tests via make prepush
  • Included comprehensive and convincing tests for changes

BREAKING CHANGE: Using setImmediate has more overhead than nextTick on
Node.js v12. Benchmarks show improvements of >20% when changing
setImmediate to nextTick:

  response-json throughput:
  {
      "significant": "***",
      "equal": false,
      "wins": "head",
      "diff": "28.62%"
  }

  ---- response-text ----
  ✔ Results saved for head/response-text
  ✔ Results saved for stable/response-text
  response-text throughput:
  {
      "significant": "***",
      "equal": false,
      "wins": "head",
      "diff": "43.45%"
  }

  ---- router-heavy ----
  ✔ Results saved for head/router-heavy
  ✔ Results saved for stable/router-heavy
  router-heavy throughput:
  {
      "significant": "***",
      "equal": false,
      "wins": "head",
      "diff": "30.02%"
  }

  ---- middleware ----
  ✔ Results saved for head/middleware
  ✔ Results saved for stable/middleware
  middleware throughput:
  {
      "significant": "***",
      "equal": false,
      "wins": "head",
      "diff": "20.78%"
  }

This changes the order some events are processed (nextTick is processed
earlier than setImmediate), thus this can be considered a breaking
change as some edge cases will notice this (as we can see in the test
changes).
@hekike hekike self-requested a review November 27, 2019 19:54
Copy link
Member

@retrohacker retrohacker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 I don't see a need for this to be a breaking change. I'd consider this an internal implementation detail; relying on the timing of the middleware at such a fine level is probably an antipattern (I don't think we have a contract for this). Suspect folks test suites might break with this change like we saw, but wouldn't expect production code to be impacted.

@@ -2111,7 +2111,7 @@ test('should increment/decrement inflight request count', function(t) {
CLIENT.get('/foo', function(err, _, res) {
t.ifError(err);
t.equal(res.statusCode, 200);
t.equal(SERVER.inflightRequests(), 1);
t.equal(SERVER.inflightRequests(), 0);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is fine. Is this a result of CLIENT and SERVER sharing an event loop? Looking at this change, I don't see how it would cause a problem with our inflight request throttling. I could see the interaction between open request throttling and inflight request throttling changing with this PR, though I don't see a use case for both of those being turned on at the same time.

@hekike
Copy link
Member

hekike commented Dec 2, 2019

We discussed that we will treat it as implementation details and making a nonbreaking release.

@hekike hekike merged commit 703470a into restify:master Dec 2, 2019
@hekike
Copy link
Member

hekike commented Dec 2, 2019

Thanks @mmarchini!
released as restify@8.5.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants