【发布时间】:2011-08-08 14:49:39
【问题描述】:
我有一个部署在一台机器上的 ASP.NET Web 应用程序和部署在另一台机器上的 C# windows 服务。 每次当用户通过网络应用发布新帖子时,我想立即向 Windows 服务发送信号以开始处理该信息。
我真的不需要传递任何参数 - 只是一个信号,表明是时候开始处理存储在数据库中的新数据块了。
如果 Windows 服务在 ~200 毫秒内收到来自 Web 应用程序的处理信号,那就太好了。
我最初的选择是将 WCF 嵌入 Windows 服务并使用 NetTcpBinding。 然而,WCF 被证明是一个不幸的选择:
1) 它需要大量不平凡的丑陋编码/配置。
2) 它非常慢 - 目前为了进行简单的调用,从一台机器调用到另一台机器需要 20 秒 (!),而这些机器之间的 ping 时间不到 1 毫秒。
3) 微软的 WCF 团队在 [缺乏] 对开发者投诉的回复方面很可悲(谷歌 http://www.google.com/search?q=wcf+client+slow 看看你自己)。
所以我正在寻找一个好的选择。
目前我的选择 #1 是 System.Net.Sockets.Socket: http://msdn.microsoft.com/en-us/library/system.net.sockets.socket.aspx
文章中的示例似乎比 WCF monstrosity 简单且简单。
您认为这是一个不错的选择吗?如果是,有没有 gothas?
有更好的方法吗?
操作系统:Windows Server 2008(生产)、Windows 7(开发)。
我已经解决了多个请求排队的问题:如果 winservice 接收到多个处理请求,它只会处理数据,直到所有新数据都被完全处理。
更新 1:为什么要投反对票?
更新 2: 偶尔松散信号也可以。无论如何,我每分钟都会重新处理 winservice 中的新帖子。我只是想确保大多数帖子在用户保存后几乎立即得到处理。
【问题讨论】:
标签: c# asp.net wcf sockets windows-services