3
我们是否正确排队和序列化？
我们通过各种服务处理消息（一条消息在完成之前可能会涉及9个服务，每个服务都具有与IO相关的特定功能）。现在，我们结合了最坏情况（XML数据协定序列化）和最佳情况（内存中的MSMQ）的性能。 消息的性质意味着我们的序列化数据最终约为12-15 KB，并且我们每周处理约400万条消息。MSMQ中的持久消息对我们来说太慢了，随着数据的增长，我们感受到了MSMQ的内存映射文件带来的压力。 该服务器的内存使用量为16GB，并且正在增长，仅用于排队。 当内存使用率很高时，由于机器开始交换，因此性能也会受到影响。我们已经在执行MSMQ自清除行为。 我觉得这里有些地方我们做错了。我尝试使用RavenDB保留消息并仅对标识符进行排队，但性能却非常慢（每分钟最多1000条消息）。我不确定这是使用开发版本还是使用什么版本，但我们确实需要更高的吞吐量[1]。该概念在理论上非常有效，但性能不能满足要求。 使用模式具有一项充当路由器的服务，该服务会进行所有读取。其他服务将基于它们的第3方挂钩附加信息，然后转发回路由器。大多数物体被触摸9至12次，尽管大约10％的物体在该系统中被迫循环一会儿，直到第三方做出适当响应为止。现在，由于这一原因，我们利用消息的优先级字段来解决此问题并具有适当的休眠行为。 因此，我的问题是，在C＃/ Windows环境中用于在离散但LAN的计算机之间传递消息的理想堆栈是什么？ 我通常从BinaryFormatter而不是XML序列化开始，但是如果更好的方法是将序列化卸载到文档存储中，那就太麻烦了。因此，我的问题。 [1]：我们的业务性质意味着我们越早处理消息，我们就越赚钱。我们已经通过经验证明，在本周晚些时候处理一条消息意味着我们赚钱的可能性较小。虽然“每分钟1000个”的性能听起来非常快，但我们确实需要将该数字提高到1万个/分钟。仅仅因为我每周在消息中提供数字并不意味着我们有整整一周的时间来处理这些消息。 ===============编辑： 附加信息 根据评论，我将添加一些说明： 我不确定序列化是我们的瓶颈。我已经对应用程序进行了基准测试，虽然序列化确实显示在热图上，但它仅占服务CPU利用率的2.5-3％。 我最担心的是我们消息的持久性和对MSMQ的潜在滥用。我们使用的是非事务性，非持久性消息，因此我们可以保持排队性能，而且我真的很希望至少有持久性消息，以便它们在重新启动后仍能生存。 添加更多的RAM是权宜之计。机器的内存已经从4GB减少到了16GB，并且越来越难以取舍以继续增加容量。 由于应用程序的星形路由模式，对象弹出一半时间然后被推到队列中，它根本不会改变。这又使（IMO）能够将其存储在其他地方的某种键值存储中，并仅传递消息标识符。 星型路由模式是应用程序不可或缺的，并且不会更改。我们无法以应用程序为中心，因为此过程中的每一部分都异步运行（以轮询方式），并且我们希望将重试行为集中在一个地方。 应用程序逻辑是用C＃编写的，对象是不可变的POCO，目标部署环境是Windows Server 2012，如果仅在Linux中支持特定软件，则允许我们站立其他计算机。 我的目标是保持当前吞吐量，同时以最小的资本支出减少内存占用并提高容错能力。