test: fix long running benchmark tests

[apapirovski]

This is a collection of changes that improve the execution time of the benchmark tests. Some are fixing missing parameters, others are slightly adjusting the benchmarks themselves, etc.

Checklist

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

[apapirovski]

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

[BridgeAR]

@apapirovski would you be so kind and check if the sequential benchmarks are now fast enough to be moved into parallel? :-)

[Trott]

@nodejs/benchmarking (not sure if the changes to the actual benchmark code might have unforeseen adverse impact on, say, rendering of graphs at https://benchmarking.nodejs.org/)

[Trott]

@nodejs/benchmarking (not sure if the changes to the actual benchmark code might have unforeseen adverse impact on, say, rendering of graphs at https://benchmarking.nodejs.org/)

Looking more closely, that seems unlikely, although it would still be great to get a review from that team.

[Trott]

node-test-commit-linuxone rerun: https://ci.nodejs.org/job/node-test-commit-linuxone/579/

[Trott]

@apapirovski would you be so kind and check if the sequential benchmarks are now fast enough to be moved into parallel? :-)

@BridgeAR There's only two modified in this PR.

One is http which can't be moved to parallel because it uses predefined ports in the benchmarks.

The other is buffer. That one is a pure refactor. This change should not affect its execution time. (This PR adds two options to the test. Those options are added to the benchmark in this PR. Net effect on run time should be approximately zero.)

[apapirovski]

This PR adds two options to the test. Those options are added to the benchmark in this PR. Net effect on run time should be approximately zero.)

To be fair, it adds those options in favour of what were currently large defaults. So it actually does affect execution time but not enough that it should go in parallel. I think it was only 10-15% faster.

[Trott]

To be fair, it adds those options in favour of what were currently large defaults. So it actually does affect execution time but not enough that it should go in parallel. I think it was only 10-15% faster.

Ah! Yes, good point. Thanks for the correction.

[apapirovski]

Landed in e5f5320...f48ca9c