You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Given that the underlining Jose package performance might fluctuate between releases it might be a good idea to add some tests to block us from doing upgrades or code changes that degrade performance.
A simple way of doing this is to measure the number of decrypts/encrypts the library can do for a minutes duration and a comfortable threshold for failing CI when the threshold is unmet.
Real-world scenario: Encrypting and decrypting A 30kb object (the telemetry snapshot object)
Basic scenario: Encrypting and decrypting A 1kb object
Node version to use for benchmarking:
Nodejs 12 will automatically adjust the old space size based on the available OS memory. Since we are using version 12 or above in Kibana (and most other users of this package) it makes sense to use nodeJS 12 for running the benchmarks similarly to what we do with running the (unit tests on CI)[https://github.com/elastic/request-crypto/blob/main/.github/workflows/prepare.yml#L17]
It might make sense however to specify the max space size for the node process
The text was updated successfully, but these errors were encountered:
@Bamieh
The only telemtry object that I see in this project is a function that calls out to get the object from the endpoint which this case can almost function as an integration test.
async function getTelemetryMetrics() { return fetch(server.telemetryEndpoint); }
@WingZer0123 yea getTelemetryMetrics is only in the README as an example. The integration tests would look something like that however, it'll basically encrypt an object and then decrypt it.
@Bamieh I noticed that you are a maintainer of mocha.js. Attempting to reproduce this functionality with in a test case in Mocha has lead to some asyc behavior I am having a hard time getting around. Even with a promises, async/await use setInterval. Do you have any suggestions?
Yes, I used to co-maintain mocha.js for a while. Do you mind sharing the code you have so I can take a look? My initial thoughts are that the encryption time varies between runs so it might cause mocha to timeout if not given enough leeway
Given that the underlining Jose package performance might fluctuate between releases it might be a good idea to add some tests to block us from doing upgrades or code changes that degrade performance.
Some additional context: cisco/node-jose#335
Proposed implementation:
A simple way of doing this is to measure the number of decrypts/encrypts the library can do for a minutes duration and a comfortable threshold for failing CI when the threshold is unmet.
Node version to use for benchmarking:
Nodejs 12 will automatically adjust the old space size based on the available OS memory. Since we are using version 12 or above in Kibana (and most other users of this package) it makes sense to use nodeJS 12 for running the benchmarks similarly to what we do with running the (unit tests on CI)[https://github.com/elastic/request-crypto/blob/main/.github/workflows/prepare.yml#L17]
It might make sense however to specify the max space size for the node process
The text was updated successfully, but these errors were encountered: