背景：我们有一个基于JMS的架构的批处理框架。以下是它的简要工作。
我们有 2 个队列，一个输入，另一个是输出。在输入队列上，我们有一个简单的处理器，它从平面文件中读取记录，并将文件拆分为称为块的记录组。此外，对于每个块，它会从线程池中生成一个线程，进而为每个块创建一个 java 对象。之后，每个对象被转换为字符串，并进一步转换为字节并发送到输入队列。在目标端，我们有 mdbs 等待消息，这些消息进一步将字节转换为字符串 amd，然后转换为 java 对象并开始处理块。处理后，结果被发送到输出队列，该队列由其他消费者进一步处理。
现在为了提高性能，我们引入了 avro 作为序列化框架。我们不是将数据作为 java 对象的块转换为字符串，然后再转换为字节，而是将数据从 chunk 复制到 avro 中，并进一步序列化相同的数据。类似地，我们使用 avro 反序列化将序列化的数据转换回块。
在完成thia之后，我们观察到我们能够将每个块的数据大小减少30%。早些时候，块大小为 220000 字节，后来减少到 150000 字节。但是，当我们尝试根据输入处理器处理所有块所花费的时间来衡量性能时，它得到了增加。例如，早期的 6000 条记录拆分为 60 个 100 个 revord 块需要 18 秒。现在在实施 avro 后，需要 20-22 秒。
问题：以上述方式衡量绩效是否正确？
在上述情况下，还有哪些其他方法可以衡量性能改进。显然，消息的大小已经减少，但我需要可靠的数据来证明改进。
P.s. 我使用输入处理器所花费的时间作为性能参数的思考过程是，如果队列上写入的数据量较少，则处理器生成的用于处理每个块的线程将更早获得自由。在这里，生成的线程数是可配置的。在上面的测量中，在线程池中配置了 2 个线程。
DataFileWriter 的默认编解码器压缩级别为 6。但是，您可能希望尝试使用其他编解码器;
- CodecFactory.bzip2Codec((
- CodecFactory.deflateCodec(9(//默认压缩级别 6
- CodecFactory.nullCodec((//无压缩
- CodecFactory.snappyCodec((
- CodecFactory.xzCodec(9(