Performance could be improved

[jsha]

Running graphene's performance tests, they don't match up to spec'ced performance, and underperform letsencrypt/pkcs11key:

# graphene
> module load -l /usr/safenet/lunaclient/lib/libCryptoki2_64.so -n SoftHSMv2.0

Module info
==============================
  Library: /usr/safenet/lunaclient/lib/libCryptoki2_64.so
  Name: SoftHSMv2.0
  Description: Chrystoki                      
  Cryptoki version: 2.20

> slot open --slot 0 -p XXXXXXXXXXXX

Session is started

> test sign -it 200 -a all

| Algorithm                 |     Sign |   Verify |   Sign/s | Verify/s |
|---------------------------|---------:|---------:|---------:|---------:|
| RSA-1024                  |   5.77ms |   2.42ms |   173.31 |  413.223 |
| RSA-2048                  | 16.715ms |  3.755ms |   59.827 |  266.312 |
| RSA-4096                  |  85.44ms |   5.54ms |   11.704 |  180.505 |
| ECDSA-SECP192R1           |  17.17ms |  19.91ms |   58.241 |   50.226 |
| ECDSA-SECP256R1           |  25.93ms |  29.52ms |   38.565 |   33.875 |
| ECDSA-SECP384R1           | 61.685ms |   72.8ms |   16.211 |   13.736 |
| ECDSA-SECP256K1           |  28.31ms |  32.76ms |   35.323 |   30.525 |
| ECDSA-BRAINPOOLP192R1     | 29.685ms | 32.465ms |   33.687 |   30.802 |
| ECDSA-BRAINPOOLP224R1     |  24.83ms | 28.735ms |   40.274 |   34.801 |
| ECDSA-BRAINPOOLP256R1     |  28.93ms |  33.23ms |   34.566 |   30.093 |
| ECDSA-BRAINPOOLP320R1     |  48.54ms | 56.265ms |   20.602 |   17.773 |

$ go get github.com/letsencrypt/pkcs11key
$ pkcs11-tool --module /usr/safenet/lunaclient/lib/libCryptoki2_64.so --slot 0 --login --pin XXXXXXXXXXX -k --key-type rsa:2048 --label "privkey"
$ go test -o pkcs11bench_test ./ && ./pkcs11bench_test -test.run xxx  -module /usr/safenet/lunaclient/lib/libCryptoki2_64.so -pin XXXXXXXXXX -tokenLabel "admin" -privateKeyLabel "privkey"  -test.bench Bench -test.v -sessions 1
ok      github.com/letsencrypt/pkcs11key        0.002s
BenchmarkPKCS11-8            100          16245245 ns/op
--- BENCH: BenchmarkPKCS11-8
        pkcs11key_bench_test.go:83: Time, count, ops / second: 16.358689ms, 1, 61.12959296432618
        pkcs11key_bench_test.go:83: Time, count, ops / second: 1.624016686s, 100, 61.57572201200893
PASS
$ go test -o pkcs11bench_test ./ && ./pkcs11bench_test -test.run xxx  -module /usr/safenet/lunaclient/lib/libCryptoki2_64.so -pin XXXXXXXXXXXXX -tokenLabel "admin" -privateKeyLabel "privkey"  -test.bench Bench -test.v -sessions 4
ok      github.com/letsencrypt/pkcs11key        0.003s
BenchmarkPKCS11-8            100          15854061 ns/op
--- BENCH: BenchmarkPKCS11-8
        pkcs11key_bench_test.go:83: Time, count, ops / second: 16.398638ms, 1, 60.98067412671711
        pkcs11key_bench_test.go:83: Time, count, ops / second: 1.583619345s, 100, 63.14648802171585
PASS

Note: with a single session, pkcs11key gets 61.6 ops/s (similar to Graphene), but with multiple sessions it gets 63.1.

[rmhrisk]

Thanks for the bug, my theory is this is because Node runs in a single event loop. It's single threaded, and you only ever get that one thread. All of the javascript you write executes in this loop, and if a blocking operation happens in that code, then it will block the entire loop and nothing else will happen until it finishes.

The above describes how Graphene works, it is not clear to me how in Node we would address this though.

We will think about it.

[rmhrisk]

@microshine We should look at https://github.com/libuv/libuv when we have time to see if we can use this to address this gap.