2017-07-26 17 views
0

背景:我们有一个具有基于jms架构的批处理框架。下面是它的一个简短的工作。在基于jms的批处理框架中实现avro序列化后,性能降低

我们有2个queues.one输入和其他输出。在输入队列中,我们有一个简单的处理器,它从平面文件中读取记录,并将文件拆分成称为块的记录组。此外,对于每个块,它会从线程池中产生一个线程,然后为每个块创建一个java对象。之后,每个对象都被转换成一个字符串并进一步转换为字节并发送到输入队列。在目标端,我们有mdbs等待消息进一步将字节转换为字符串amd,然后转换为java对象并开始处理块。处理后,结果被发送到输出队列,由其他消费者进一步处理。

现在为了提高性能,我们引入了avro作为序列化框架。我们不是将块是一个java对象转换为一个字符串,然后转换为字节,而是将数据从块复制到avro中,并进一步将其序列化。类似的方法,我们使用avro反序列化将序列化的数据转换回块。

在做好了thia后,我们观察到我们能够将每个块的数据大小减少30%。较早的块大小为220000字节,其减少到150000字节。但是,当我们试图根据输入处理器处理所有组块所花费的时间来衡量性能时,它会增加。例如。早期的6000个记录分成60个100个revords块需要18秒。现在实施avro后,它需要20-22秒。

问题:正在以上述方式测量性能的正确方法吗?

在上述情况下,衡量绩效改进的其他方法有哪些?显然,消息的大小已经减少,但我需要可靠的数据来证明改进。

P.s.我将使用输入处理器所花费的时间作为性能参数的思想过程是,如果要写入队列的数据量较少,则处理器产生的用于处理每个块的线程将更早释放。这里,产生的线程数量是可配置的。在上面的测量中,线程池中配置了2个线程。

回答

0

DataFileWriter的默认编解码器的压缩级别为6压缩。但是,您可能想要尝试其他编解码器;

  • CodecFactory.bzip2Codec()
  • CodecFactory.deflateCodec(9)//默认压缩级别6
  • CodecFactory.nullCodec()//没有压缩
  • CodecFactory.snappyCodec()
  • CodecFactory中.xzCodec(9)