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

benchmark, test: test the HTTP benchmark with a dummy benchmarker #12121

Closed
wants to merge 4 commits into from

Conversation

joyeecheung
Copy link
Member

@joyeecheung joyeecheung commented Mar 29, 2017

This is a retake of #12025, it basically just goes with the last option in #12025 (comment), makes a dummy http benchmarker to connect to the benchmarked http server once, and sets all the numeric benchmark configurations to the minimal.

  • The first commit also refactors _http-benchmarks a bit to use ES6 classes.
  • The second commit also moves http/_http_simple.js to fixtures/simple-http-server.js since it is not a benchmark itself

This adds about 10s to the test running time on my mac (i7-4770HQ CPU @ 2.20GHz) (as comparison, test-benchmark-net.js runs for about 5s)

Refs: #12068

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines
Affected core subsystem(s)

test, benchmark

@nodejs-github-bot nodejs-github-bot added benchmark Issues and PRs related to the benchmark subsystem. test Issues and PRs related to the tests. labels Mar 29, 2017
@joyeecheung
Copy link
Member Author

/cc @Trott @nodejs/benchmarking @nodejs/build

CI: https://ci.nodejs.org/job/node-test-pull-request/7089/

@vsemozhetbyt vsemozhetbyt added the http Issues or PRs related to the http subsystem. label Mar 29, 2017
@joyeecheung
Copy link
Member Author

It's timing out on pi1-raspbian-wheezy..should we skip this test on these slower devices, or set a larger timeout for them? (not sure how to do this)

@joyeecheung
Copy link
Member Author

joyeecheung commented Mar 29, 2017

There is also another way to fix the timeout: test the benchmarks one by one in multiple tests using --filter of benchmark/run.js instead of checking them all in one test.

@Trott
Copy link
Member

Trott commented Mar 29, 2017

Love it! I'd be OK with "fixing" the Pi timing out problem by not running this test on Pi. Since it's just the Pi 1 that is failing you can do this:

if (!common.enoughTestMem) {
  common.skip('Insufficient memory for HTTP benchmark test');
  return;
}

@@ -0,0 +1,7 @@
'use strict';
Copy link
Member

Choose a reason for hiding this comment

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

not intending to be pedantic... but can we use _noop-benchmarker (noop for non-operational) instead of _dummy-....

Copy link
Member

@Trott Trott Mar 29, 2017

Choose a reason for hiding this comment

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

I don't like noop because noop means "no operator". A noop should do nothing whatsoever. But that's not the case here.

In this case, this is a test double, so _test-double-benchmarker maybe? Sometimes people call certain types of test doubles mocks and other types stubs, so mock-benchmarker or stub-benchmarker might also be appropriate. (I stick to test double so that I don't have to worry about whether or not something is a mock or a stub.)

Copy link
Member

@Trott Trott Mar 29, 2017

Choose a reason for hiding this comment

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

Also, I'm fine with whatever name because this is an internal thing and we can always change it later. So if @jasnell or someone else disagrees with my suggestions,
¯\(ツ)/¯.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah it's not really a noop since it does connects to the server (a real noop-benchmarker would just skip the http.get call and write to stdout straight away). I think _test-double-benchmarker is better :D

num: [1, 4, 8, 16],
size: [1, 64, 256],
n: [1, 4, 8, 16],
len: [1, 64, 256],
Copy link
Member

Choose a reason for hiding this comment

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

why change these?

Copy link
Member Author

Choose a reason for hiding this comment

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

So test-benchmark-http.js can set the parameters for it (otherwise it will need to add --set num=1 --set size=1...also I think it's better to keep the configuration names consistent)

Copy link
Member Author

Choose a reason for hiding this comment

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

Also if we want to do #12068, doing this to other benchmarks too will make it eaiser..

@joyeecheung
Copy link
Member Author

Renamed dummy-benchmarker to test-trouble-benchmarker and skip test on Pi 1..PTAL, thanks @jasnell @Trott

New CI: https://ci.nodejs.org/job/node-test-pull-request/7150/

@joyeecheung
Copy link
Member Author

node-test-commit-osx took 2h30m to run..although it doesn' seem to be related to this PR since https://ci.nodejs.org/job/node-test-commit-osx/8734/ and https://ci.nodejs.org/job/node-test-commit/8819/ took more than 2 hours too?

@joyeecheung
Copy link
Member Author

Launch a osx CI against this one: https://ci.nodejs.org/job/node-test-commit-osx/8737/
and against master: https://ci.nodejs.org/job/node-test-commit-osx/8736/

@Trott
Copy link
Member

Trott commented Apr 1, 2017

I think you meant to rename it test-double/TestDouble rather than test-trouble/testTrouble...

@joyeecheung
Copy link
Member Author

It's double now, thanks for catching that @vsemozhetbyt @Trott :D
new CI: https://ci.nodejs.org/job/node-test-pull-request/7152/

Copy link
Member

@Trott Trott left a comment

Choose a reason for hiding this comment

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

LGTM if CI is green

@Trott
Copy link
Member

Trott commented Apr 5, 2017

@jasnell Is @joyeecheung's answer to your question "why change the config property names" sufficient? If so can you update your review so this can be unblocked?

@joyeecheung Can you rebase?

(I'd really like to see this land. :-D )

@jasnell
Copy link
Member

jasnell commented Apr 6, 2017

Yes. It's fine. I can't clear my review from the mobile view. This lgtm

@gibfahn gibfahn dismissed jasnell’s stale review April 6, 2017 07:25

No longer accurate

@joyeecheung
Copy link
Member Author

@Trott
Copy link
Member

Trott commented Apr 8, 2017

CI failures are unrelated. LGTM.

@joyeecheung
Copy link
Member Author

joyeecheung commented Apr 9, 2017

Landed in c095394...2d3d4cc, thanks!

@joyeecheung joyeecheung closed this Apr 9, 2017
joyeecheung added a commit that referenced this pull request Apr 9, 2017
Refactor benchmark/_http-benchmarkers.js and add a test double
HTTP benchmarker for testing.

PR-URL: #12121
Refs: #12068
Reviewed-By: Rich Trott <[email protected]>
Reviewed-By: James M Snell <[email protected]>
joyeecheung added a commit that referenced this pull request Apr 9, 2017
PR-URL: #12121
Refs: #12068
Reviewed-By: Rich Trott <[email protected]>
Reviewed-By: James M Snell <[email protected]>
joyeecheung added a commit that referenced this pull request Apr 9, 2017
PR-URL: #12121
Refs: #12068
Reviewed-By: Rich Trott <[email protected]>
Reviewed-By: James M Snell <[email protected]>
@italoacasas
Copy link
Contributor

cc @joyeecheung

@joyeecheung
Copy link
Member Author

Some of the changes depend on #10558, but should still be backportable. Doing a backport now...

joyeecheung added a commit to joyeecheung/node that referenced this pull request Apr 11, 2017
Refactor benchmark/_http-benchmarkers.js and add a test double
HTTP benchmarker for testing.

PR-URL: nodejs#12121
Refs: nodejs#12068
joyeecheung added a commit to joyeecheung/node that referenced this pull request Apr 11, 2017
joyeecheung added a commit to joyeecheung/node that referenced this pull request Apr 11, 2017
@jasnell jasnell mentioned this pull request May 11, 2017
@gibfahn
Copy link
Member

gibfahn commented Jun 8, 2017

@joyeecheung do you think it makes sense to backport this to Node 6?

If it is backported it should land with #13109 and #13390

@joyeecheung
Copy link
Member Author

@gibfahn The new benchmark suite does not exist in 6.x so it can not be backported.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
benchmark Issues and PRs related to the benchmark subsystem. http Issues or PRs related to the http subsystem. test Issues and PRs related to the tests.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants