在基于jms的批处理框架中实现avro序列化后，性能降低
背景：我们有一个基于jms架构的批处理框架。下面是它的简要工作。
我们有2queues.one输入和其他输出。在输入队列中，我们有一个简单的处理器，它从一个平面文件中读取记录，并将文件分成称为块的记录组。此外，对于每个块，它从线程池中生成一个线程，线程池反过来为每个块创建一个java对象。之后，每个对象被转换成字符串，并进一步转换成字节并发送到输入队列。在目标端，我们有mdbs等待消息，这些消息进一步将字节转换为字符串amd，然后转换为java对象，并开始处理块。处理后，结果被发送到输出队列，由其他消费者进一步处理。
现在为了提高性能，我们引入了avro作为序列化框架。我们没有将chunk（java对象）转换为字符串，然后转换为字节，而是将chunk中的数据复制到avro中，并进一步序列化。类似地，我们使用avro反序列化将序列化的数据转换回块。
在做了thia之后，我们观察到我们能够将每个块的数据大小减少30%。早些时候，块大小是220000字节，减少到150000字节。然而，当我们试图用输入处理器处理所有块所需的时间来衡量性能时，它增加了。例如，早期的6000条记录分成60大块的100条记录需要18秒。现在实现avro后，需要20-22秒。
问题：以上述方式衡量绩效是否正确？
在上述场景中，还有哪些其他衡量性能改进的方法。显然，消息的大小已经减少，但我需要可靠的数据来证明改进。
另外，我将输入处理器占用的时间用作性能参数的思想过程是，如果要在队列上写入的数据量较少，则处理器为处理每个数据块而生成的线程将提前释放。在这里，生成的线程数是可配置的。在上述测量中，在线程池中配置了两个线程。
共有1个答案
DataFileWriter的默认编解码器压缩级别为6。但是，您可能希望尝试使用其他编解码器；
- 这家工厂。bzip2Codec（）
- 这家工厂。deflateCodec（9）//默认压缩级别6
- 这家工厂。nullCodec（）//无压缩
- 这家工厂。snappyCodec（）
- 这家工厂。xzCodec（9）
-
本文向大家介绍Spring batch批处理框架，包括了Spring batch批处理框架的使用技巧和注意事项，需要的朋友参考一下 spring batch框架的简介 批处理任务是大多数IT项目的一个重要组成部分，批处理在业务系统中负责处理海量的数据，无须人工干预就能够自动高效的进行复杂的数据分析和处理。批处理会定期读入批量数据，经过相应的业务处理进行归档的业务操作，批处理的特征是自动执行，处理的
-
在Anylogic模型中，我的源块根据定义代理必须到达哪个节点的数据库值在不同节点上生成代理。 相同位置的订单同时到达（例如，7:30，3个代理订单到达node1，4个代理订单到达node2）。 现在我想做的是，节点1上的订单生成一批1x2和1x1，而节点2上的订单生成一批2。这些代理将扣押将这些批次运输到同一位置的运输公司，然后解除批次。 因此，我的问题是如何基于从数据库加载的Arrivaloc
-
问题内容： 我们有一个Hadoop集群，我们在上面存储使用Kryo（序列化框架）序列化为字节的数据。我们用于此目的的Kryo版本是从2.21正式版本派生而来的，以将我们自己的补丁应用于我们使用Kryo遇到的问题。当前的Kryo版本2.22也解决了这些问题，但是具有不同的解决方案。结果，我们不能仅仅更改我们使用的Kryo版本，因为这意味着我们将不再能够读取已经存储在Hadoop集群中的数据。为了解决
-
问题内容： 像其他几个人一样，我在序列化Entity Framework对象时遇到问题，因此我可以通过JSON格式的AJAX发送数据。 我有以下服务器端方法，我正在尝试通过jQuery使用AJAX进行调用 通过AJAX调用会导致此错误： 这是因为实体框架创建循环引用以保持所有对象相关并且可访问服务器端的方式。 我从（http://hellowebapps.com/2010-09-26/produc
-
反正可以禁用SQL，我只是想测试我的读写器和处理器工作正常。
-
考虑一个阶跃豆： 要求：在Reader中，它从文件中读取（Entity1的）记录。在处理器中，它进行处理，在Writer中，它写入数据库。 在TaskExecutor之前，只创建了一个线程，它将在读取器和处理器中循环1000次，如上面的块设置中所定义的。然后它将移动到writer并写入所有1000条记录。它将再次从记录编号1001开始，然后在读取器和处理器中处理另外1000条记录。这是一个同步执行