我们使用测试性能的工具，unixbench，它有一下几项测试项目：
Execl Throughput 每秒钟执行 execl 系统调用的次数
Pipe Throughput 一秒钟内一个进程向一个管道写 字节数据然后再读回的次数
Pipe-based Context Switching 两个进程（每秒钟）通过一个管道交换一个不断增长的整数的次数
Process Creation 每秒钟一个进程可以创建子进程然后收回子进程的次数（子进程一定立即退出）
Shell Scripts ( concurrent) 一秒钟一个进程可以并发地开始一个 shell 脚本的 个拷贝的次数
Shell Scripts ( concurrent) 一秒钟内一个进程可以并发地开始一个 shell 脚本的 个拷贝的次数
System Call Overhead 进入和离开操作系统内核的代价
测试结果类似如下：
Benchmark Run: Wed Apr :: - ::
CPUs in system; running parallel copy of testsDhrystone using register variables 24249307.1 lps (10.0 s, samples)
Double-Precision Whetstone 2867.3 MWIPS (10.0 s, samples)
Execl Throughput 2447.9 lps (29.9 s, samples)
File Copy bufsize maxblocks 547726.0 KBps (30.0 s, samples)
File Copy bufsize maxblocks 149186.7 KBps (30.0 s, samples)
File Copy bufsize maxblocks 1297448.0 KBps (30.0 s, samples)
Pipe Throughput 946343.5 lps (10.0 s, samples)
Pipe-based Context Switching 186950.1 lps (10.0 s, samples)
Process Creation 7092.8 lps (30.0 s, samples)
Shell Scripts ( concurrent) 5631.6 lpm (60.0 s, samples)
Shell Scripts ( concurrent) 2726.4 lpm (60.0 s, samples)
System Call Overhead 905666.4 lps (10.0 s, samples)
测试了/boot/grub2/grub.cfg 中audit=0，和去除audit=0，以及开启auditd服务等的性能数据：
1、内核参数去掉audit=0,auditd服务默认不启动：这种情况性能没有太大变化；
2、服务开启，auditctl -D删除所有可配置规则：这种情况Pipe Throughput下降近20%，System Call Overhead下降35%，其他下降%2-10%左右；
3、删除所有规则,配置 -a never,task取消系统调用的审计：性能没有太大变化；
4、配置-a never,task，配置audit目录访问，提权，账户变更等基本规则：性能变化不大；
5、audit服务开启，配置pci-dss规则，没有取消系统调用审计：Pipe Throughput下降近30%，System Call Overhead下降近50%，Pipe-based Context Switching下降10%，其他下降%2-10%左右；
从性能结果可以看到，开启内核参数，这个对性能影响不大，但是开启auditd服务后对性能影响就比较明显。
这里需要注意的是，如果auditd服务开启后，再服务停止，auditctl –e 0，性能也没有上升，依然比较差，是因为在audit内核处理中，会判断是否曾经开启过即auditctl -s查询的enabled项，只要开启了，即使后面设置auditctl –e 0后，系统调用依然会走audit流程，这就会影响系统性能。具体代码在arch/x86/kernel/entry_64.S，copy_process()中 ，int audit_alloc函数。
另外，如果配置 -a never,task后，所有的审计 type类型为SYSCALL的都不会记录了，一般情况下是要对系统调用进行审计的。
