Appendix6

This graph presents the results of the performance tests we ran on IKey+, the blue bars represent the time necessary for each test to complete, and the red curve represents the number of queries rejected by IKey+ for each test (IKey+ rejects any query received when the CPU load of the host server is greater than 80%).
These results clearly show that, among the parameters available to the end-user, only the score method parameter has a significant influence on the time needed to complete the test (tests 2d & 2e)
The results of tests 4a to 4c show that increasing the number of simultaneous threads querying IKey+ increases the number of rejected queries.
On the other hand, the test 4d shows that adding a random delay (0-1000 ms) at the start of each thread decreases the number of rejected queries dramatically, even with a large number of simultaneous threads (100 in test 4d). This is encouraging, since we consider this setup to be the closest to a production environment.

本图表展示了我们针对IKey+开展的性能测试结果。其中蓝色柱状图代表每项测试完成所需耗时，红色曲线则代表每项测试中IKey+拒绝的查询请求数量——当宿主服务器的CPU负载超过80%时，IKey+会直接拒绝收到的所有查询请求。
测试结果清晰表明，在终端用户可配置的参数中，仅评分方法参数对测试完成耗时存在显著影响（对应测试2d与2e）。
测试4a至4c的结果显示，并发查询IKey+的线程数量越多，被拒绝的查询请求总数也就越高。
与之相反，测试4d的结果表明，在每个线程启动之初添加0至1000毫秒的随机延迟，可大幅降低被拒绝的查询请求数量，即便在高并发线程数（测试4d中为100线程）的场景下亦是如此。鉴于该测试场景最贴近真实生产环境，这一发现令人备受鼓舞。