benchmark: update iterations in benchmark/crypto/aes-gcm-throughput.js

[lucshi]

Refs: #50571

Below is score improvement from 500 to 2500, measured on Cascake server.
Improvement can be a bit more if changing to 5000 but the running time will be notable longer than appropriate duration.

To make it clear, I will submit more PRs one by one to address each case in crypto, and tracked by 50571 issue.

crypto/aes-gcm-throughput.js cipher="aes-128-gcm" 554.5625838906785 n=2500 percent=144.46% crypto/aes-gcm-throughput.js cipher="aes-128-gcm" n=2500 percent=134.25% crypto/aes-gcm-throughput.js cipher="aes-128-gcm" n=2500 percent=136.22% crypto/aes-gcm-throughput.js cipher="aes-128-gcm" n=2500 percent=151.78% crypto/aes-gcm-throughput.js cipher="aes-128-gcm" n=2500 percent=125.49% crypto/aes-gcm-throughput.js cipher="aes-192-gcm" 557.082005808399 n=2500 percent=131.03% crypto/aes-gcm-throughput.js cipher="aes-192-gcm" n=2500 percent=131.05% crypto/aes-gcm-throughput.js cipher="aes-192-gcm" n=2500 percent=136.30% crypto/aes-gcm-throughput.js cipher="aes-192-gcm" n=2500 percent=149.98% crypto/aes-gcm-throughput.js cipher="aes-192-gcm" n=2500 percent=123.60% crypto/aes-gcm-throughput.js cipher="aes-256-gcm" 557.9763934240019 n=2500 percent=130.56% crypto/aes-gcm-throughput.js cipher="aes-256-gcm" n=2500 percent=130.17% crypto/aes-gcm-throughput.js cipher="aes-256-gcm" n=2500 percent=135.86% crypto/aes-gcm-throughput.js cipher="aes-256-gcm" n=2500 percent=148.04% crypto/aes-gcm-throughput.js cipher="aes-256-gcm" n=2500 percent=123.15% 

[H4ad]

I don't think that worth changing from 500 to 2500, I don't think this will trigger any optimization by V8.

[lucshi]

I don't think that worth changing from 500 to 2500, I don't think this will trigger any optimization by V8.

Hi Vinicius,

The rational of this change is not to trigger JIT, but make the crypto code dominate the execution phase instead of fwrite. When the iteration was 500, most execution time was occupied by fwrite. When iterations was increased to 2500, most execution time would be occupied by crypto. To make the scoring reasonable, we need to increase the iterations. After some experiments I found 2500 is a proper value to avoid long execution time.

I attached the perf log of 500 and 2500 and please see if the change made sense. Thanks!

2500.perf.log
500.perf.log

[H4ad]

In this case, make sense, thanks for the PR.

[nodejs-github-bot]

Landed in 29af78e