RFR: 8330108: Increase CipherInputStream buffer size

[Anthony Scarpino]

On Fri, 12 Apr 2024 16:49:49 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Increase buffer size in CipherInputStream from 512 bytes to 8192 bytes.
>> 
>> I have seen applications where this small buffer size significantly reduces throughput, and I've even seen applications which use reflection to modify the buffer size to work around the issue.
>> 
>> Using the existing `AESGCMCipherInputStream` benchmark, we can see that 8192 performs better in all the explored cases than 512. Sometimes other sizes beat 8192, but it seems a good compromise of performance across encrypt/decrypt and memory usage, plus it's in line with other JDK classes like ChannelInputStream and FileInputStream.
>> 
>> ### Benchmark results
>> 
>> 
>> make test TEST=micro:org.openjdk.bench.javax.crypto.full.AESGCMCipherInputStream
>> 
>> 
>> 8192 wins substantially for encrypt of both data sizes, and wins noticeably for small decrypt data size, while remaining roughly equal for large decrypt data size (why are the error bars so wide there...?)
>> 
>> 
>>  (benchmark)  (dataSize)        Score      Error  Units
>> == buffer size = 512 (current) ==
>>    decrypt         16384    41800.053 +-  674.761  ops/s
>>    decrypt       1048576      219.218 +- 4509.696  ops/s
>>    encrypt         16384    59481.957 +- 2297.546  ops/s
>>    encrypt       1048576     1030.822 +-   48.273  ops/s
>>    
>> == buffer size = 8192 (this PR) ==
>>    decrypt         16384    45023.512 +-  351.284  ops/s
>>    decrypt       1048576      217.506 +- 4498.711  ops/s
>>    encrypt         16384    71678.424 +- 1731.105  ops/s
>>    encrypt       1048576     1562.457 +-   50.944  ops/s
>> 
>> == other candidates (rejected) ==
>> buffer size = 128
>>    decrypt         16384    36282.200 +- 3827.690  ops/s
>>    decrypt       1048576      200.096 +- 3972.338  ops/s
>>    encrypt         16384    38352.717 +- 5030.671  ops/s
>>    encrypt       1048576      671.195 +-   84.134  ops/s
>> buffer size = 2048
>>    decrypt         16384    44411.579 +- 2452.429  ops/s
>>    decrypt       1048576      224.036 +- 4582.988  ops/s
>>    encrypt         16384    65907.313 +- 2678.562  ops/s
>>    encrypt       1048576     1232.242 +-   53.233  ops/s
>> buffer size = 32768
>>    decrypt         16384    51004.362 +- 3147.855  ops/s
>>    decrypt       1048576      205.818 +- 4233.473  ops/s
>>    encrypt         16384    58716.428 +-  269.514  ops/s
>>    encrypt       1048576     1564.075 +-   43.732  ops/s
>> buffer size = 131702
>>    decrypt         16384    32111.911 +-  766.159  ops/s
>>    decrypt       1048576      247.852 +- 5533.972...
>
> Can you provide memory usage difference between the current and your suggested change with `-prof gc`?  With many of these situations, it's a balance between memory usage and performance.

> @ascarpino here's the `-prof gc` results. Allocations per operation are very similar except for encryption for the smaller data size which is significantly increased with the higher buffer size. I think it's a good tradeoff.
> 

Benchmark                      (dataSize)        Score        Error   Units
== buffer size = 512 (current) ==
encrypt:gc.alloc.rate            16384         1991.982 +-   162.581  MB/sec
encrypt:gc.alloc.rate          1048576         1062.342 +-     4.239  MB/sec
== buffer size = 8192 (this PR) ==
encrypt:gc.alloc.rate            16384         4066.224 +-   338.790  MB/sec
encrypt:gc.alloc.rate          1048576         1615.335 +-    36.420  MB/sec


@olivergillespie Thanks for the data.  Any theories why encryption memory usage jumped up when the decryption are very close?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18763#issuecomment-2057660699