Encryption 加密与未加密的EBS卷AWS
我们正在测试标准EBS卷，在EBS优化的m3.xlarge EC2实例上使用加密的EBS卷 在分析测试结果时，我们了解到 与未加密的EBS相比，使用加密的EBS卷在读、写、读/写操作期间花费的时间更少。 我认为延迟会对加密的EBS卷产生影响，因为每个I/O请求都会有额外的加密开销 EBS加密卷比普通EBS卷快的适当原因是什么 预期结果应该是EBS应该产生比加密EEB更好的结果 结果：Encryption 加密与未加密的EBS卷AWS,encryption,amazon-web-services,amazon-ec2,Encryption,Amazon Web Services,Amazon Ec2,我们正在测试标准EBS卷，在EBS优化的m3.xlarge EC2实例上使用加密的EBS卷 在分析测试结果时，我们了解到 与未加密的EBS相比，使用加密的EBS卷在读、写、读/写操作期间花费的时间更少。 我认为延迟会对加密的EBS卷产生影响，因为每个I/O请求都会有额外的加密开销 EBS加密卷比普通EBS卷快的适当原因是什么 预期结果应该是EBS应该产生比加密EEB更好的结果 结果： sysbench 0.4.12: multi-threaded system evaluation bench
sysbench 0.4.12: multi-threaded system evaluation benchmark
Running the test with following options:
Number of threads: 8
Initializing random number generator from timer.
Extra file open flags: 16384
8 files, 512Mb each
4Gb total file size
Block size 16Kb
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing sequential write (creation) test
Threads started!
Done.
Operations performed: 0 Read, 262144 Write, 8 Other = 262152 Total
Read 0b Written 4Gb Total transferred 4Gb (11.018Mb/sec)
705.12 Requests/sec executed
Test execution summary:
total time: 371.7713s
total number of events: 262144
total time taken by event execution: 2973.6874
per-request statistics:
min: 1.06ms
avg: 11.34ms
max: 3461.45ms
approx. 95 percentile: 1.72ms
sysbench 0.4.12: multi-threaded system evaluation benchmark
Running the test with following options:
Number of threads: 8
Initializing random number generator from timer.
Extra file open flags: 16384
8 files, 512Mb each
4Gb total file size
Block size 16Kb
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing sequential write (creation) test
Threads started!
Done.
Operations performed: 0 Read, 262144 Write, 8 Other = 262152 Total
Read 0b Written 4Gb Total transferred 4Gb (6.3501Mb/sec)
406.41 Requests/sec executed
Test execution summary:
total time: 645.0251s
total number of events: 262144
total time taken by event execution: 5159.7466
per-request statistics:
min: 0.88ms
avg: 19.68ms
max: 5700.71ms
approx. 95 percentile: 6.31ms
sysbench 0.4.12: multi-threaded system evaluation benchmark
Running the test with following options:
Number of threads: 8
Initializing random number generator from timer.
Extra file open flags: 16384
8 files, 512Mb each
4Gb total file size
Block size 16Kb
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing sequential write (creation) test
Threads started!
Done.
Operations performed: 0 Read, 262144 Write, 8 Other = 262152 Total
Read 0b Written 4Gb Total transferred 4Gb (11.018Mb/sec)
705.12 Requests/sec executed
Test execution summary:
total time: 371.7713s
total number of events: 262144
total time taken by event execution: 2973.6874
per-request statistics:
min: 1.06ms
avg: 11.34ms
max: 3461.45ms
approx. 95 percentile: 1.72ms
sysbench 0.4.12: multi-threaded system evaluation benchmark
Running the test with following options:
Number of threads: 8
Initializing random number generator from timer.
Extra file open flags: 16384
8 files, 512Mb each
4Gb total file size
Block size 16Kb
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing sequential write (creation) test
Threads started!
Done.
Operations performed: 0 Read, 262144 Write, 8 Other = 262152 Total
Read 0b Written 4Gb Total transferred 4Gb (6.3501Mb/sec)
406.41 Requests/sec executed
Test execution summary:
total time: 645.0251s
total number of events: 262144
total time taken by event execution: 5159.7466
per-request statistics:
min: 0.88ms
avg: 19.68ms
max: 5700.71ms
approx. 95 percentile: 6.31ms
sysbench 0.4.12: multi-threaded system evaluation benchmark
Running the test with following options:
Number of threads: 8
Initializing random number generator from timer.
Extra file open flags: 16384
8 files, 512Mb each
4Gb total file size
Block size 16Kb
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing sequential write (creation) test
Threads started!
Done.
Operations performed: 0 Read, 262144 Write, 8 Other = 262152 Total
Read 0b Written 4Gb Total transferred 4Gb (11.018Mb/sec)
705.12 Requests/sec executed
Test execution summary:
total time: 371.7713s
total number of events: 262144
total time taken by event execution: 2973.6874
per-request statistics:
min: 1.06ms
avg: 11.34ms
max: 3461.45ms
approx. 95 percentile: 1.72ms
sysbench 0.4.12: multi-threaded system evaluation benchmark
Running the test with following options:
Number of threads: 8
Initializing random number generator from timer.
Extra file open flags: 16384
8 files, 512Mb each
4Gb total file size
Block size 16Kb
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing sequential write (creation) test
Threads started!
Done.
Operations performed: 0 Read, 262144 Write, 8 Other = 262152 Total
Read 0b Written 4Gb Total transferred 4Gb (6.3501Mb/sec)
406.41 Requests/sec executed
Test execution summary:
total time: 645.0251s
total number of events: 262144
total time taken by event execution: 5159.7466
per-request statistics:
min: 0.88ms
avg: 19.68ms
max: 5700.71ms
approx. 95 percentile: 6.31ms
请帮我解决这个问题。这在概念上肯定是出乎意料的，也得到了以下方面的证实： […]和加密卷上的配置IOPS性能与未加密卷上的配置IOPS性能相同，对延迟的影响最小。您可以使用访问现有卷的相同方式访问加密的Amazon EBS卷；加密和解密是透明处理的，不需要您、EC2实例或应用程序执行额外操作。[…][我的重点] 提供有关EBS总体性能的更多详细信息-从这个角度来看，但纯粹是猜测，可能使用加密意味着某些默认： 当您创建任何新的EBS卷（通用（SSD）、配置的IOPS（SSD）或磁卷）或从快照恢复卷时，后端存储块将立即分配给您。但是，首次访问存储块时，必须将其清除（对于新卷）或从其快照实例化（对于还原的卷），然后才能访问该块。此初步操作需要时间，在第一次访问每个数据块时，可能会导致卷的IOPS损失5%到50%。[……]
无论哪种方式，我建议在预热两个新EBS卷后重新运行基准测试，以防您还没有这样做。我已经在相同的卷上运行了近3次测试。每次我收到相同的列表时，即加密的EBS都比EBS卷具有更好的性能。我现在该怎么办？请注意，我没有使用PIOPS卷。我正在进行磁性（称为标准）体积的测试，但。。。您是否确实对整个卷进行了预热？我也使用dd命令完成了这项工作，但是结果很奇怪。这已经很旧了，但是：没有足够的关于磁体积的信息。AWS表示，它们可以达到数百IOPS，但不要提及是基于信用还是什么。不确定测试的顺序，但这些突发事件可能会影响结果。尝试切换测试顺序。