asp.net-mvc-3 – Azure服务总线 – 双向通信性能挑战

问题似乎是创建和删除这些Subscription对象.开销很大,并且会使应用程序变慢.这并不是说要解决的各种限制,例如主题上的订阅数量不超过2000个.

在发布者和订阅者之间建立这种双向通信的最佳实践是什么？我们希望MVC3应用程序发布消息,然后等待对该确切消息的响应(通过CorrelationId属性和CorrelationFilter).我们已经缓存了NamespaceManager和MessagingFactory,因为它们在资源方面也非常昂贵,并且还因为我们被告知Service Bus使用显式配置模型,我们需要在角色启动期间预先创建大部分这些内容.

因此,这给我们带来了将请求与响应相关联的挑战,以及创建和删除订阅的巨大开销.还有什么更好的做法？我们应该保留SubscriptionClient的缓存,并每次交换过滤器吗？其他人都做了什么？我需要通过Web角色群集获得每秒5到10,000个MVC3请求的请求吞吐量.我们已经在使用AsyncController并在SubscriptionClient上使用异步BeginReceive().它似乎是数以千计的订阅的创建和删除,此时系统正在窒息.

UPDATE1：
根据此处提供的出色建议,我们更新了此解决方案,以便在每个Web角色实例上保留SubscriptionClient对象的缓存.此外,我们已迁移到面向MessageSession的方法.

但是,这仍然没有缩放.似乎AcceptMessageSession()是一个非常昂贵的操作. MessageSession对象是否也应该被缓存并重新使用？每个打开的MessageSession对象是否都使用与服务总线的连接？如果是这样,这是否与订阅的并发连接配额相对应？

非常感谢.我想我们到了那里. Web上的大多数示例代码显示：在客户端上创建Topic(),然后是CreateSubscription(),然后是CreateSubscriptionClient(),然后是BeginReceive(),然后拆除所有对象.我只能说,如果你在现实生活中这样做,你的服务器就会被粉碎,你最快就能连接起来了.

我们需要通过这个东西每秒发出数千个请求,很明显这些对象必须被高速缓存和重用.那么,MessageSession还有另一个要缓存的项目吗？我将获得有趣的缓存,因为我们必须实现一个引用计数机制,其中一次只能给出一个对MessageSession的引用,因为这是针对http请求特定的请求/响应,我们不能有其他订阅者同时使用MessageSession对象.

UPDATE2：
好吧,缓存MessageSession以便重复使用是不可行的,因为它们只与订阅时的LockDuration一样长.这是一个无赖,因为最大LockDuration是5分钟.这些似乎是短期的pub / sub,而不是长期运行的分布式进程.看起来我们需要回到轮询Azure表.

发明内容/评注
由于规模潜力及其持久性和交付语义,我们尝试构建Service Bus.但是,似乎有些情况下,它们之间的大量请求/响应不适合它.发布部分工作得很好,并且在后端拥有竞争的消费者是很好的,但是有一个前端请求等待定义的单一消费者响应,根本不能很好地扩展,因为MessageSessions需要太长时间才能完成通过AcceptMessageSession()或BeginAcceptMessageSession()创建,因为它们不适合缓存.

如果有人有另一种观点,我很乐意听到.