netTcpBinding/BasicHttpBinding

发布于 2024-12-22 01:27:44 字数 166 浏览 1 评论 0原文

有人可以帮助了解 netTcpBinding 与 BasicHttpBinding 之间的主要区别吗?

在我当前的项目中,我们将 BasicHttpBinding 转换为 netTcpBinding 并遇到性能问题,即使 BizTalk 中的值设置为 1:00:00,它也会开始超时。我们不明白为什么?

Can someone help to what are the major diff between netTcpBinding v/s BasicHttpBinding ?

In my current project we convert BasicHttpBinding to netTcpBinding and get performance issue, it start timing out even thou the value in BizTalk is set to 1:00:00. We couldn't figure out why ?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

ˇ宁静的妩媚 2024-12-29 01:27:44

netTcp 和 basicHttp 绑定使用完全不同的传输机制:TCP 而不是 HTTP。理论上来说,TCP的二进制编码应该比HTTP的文本编码要快。

正如所讨论的 此处,由于额外的安全开销和/或争用,netTcpBinding 可能不会那么快:

默认情况下,NetTcpBinding 启用某些级别的安全添加
WCF 运行时的消息处理管道的开销。
此外,NetTcpBinding还启用端口共享功能
这意味着您的 WCF 主机不会独占访问该端口
相反,可能会与其他应用程序共享它。这可能会得到
如果您在 Windows Server 中托管服务,则非常有趣
2008或Windows 7环境鉴于有多个Windows
依赖 NetTcpBinding 端点的应用程序。最后,
ListenBacklog 和 MaxConnections 设置的默认值为
设置为 10,这对于大量客户端而言远非最佳。

另请注意,如果没有有关通信哪一部分超时的更多信息,则很难说出确切的原因。请记住,交易的每一方对于“打开”、“关闭”以及“发送或接收”都有不同的超时设置。

netTcp and basicHttp bindings use entirely different transport mechanisms: TCP instead of HTTP. In theory, the binary encoding of TCP should be faster than the text encoding of HTTP.

As discussed here, netTcpBinding may not be as fast, because of additional security overhead and/or contention:

By default, NetTcpBinding enables certain levels of security add
overhead to the message processing pipeline of the WCF runtime.
Additionally, the NetTcpBinding also enables the port sharing feature
which means that your WCF host won’t have exclusive access to the port
and instead might share it with other applications. This might get
very interesting if you are hosting your service in a Windows Server
2008 or Windows 7 environment given that there are a number of Windows
applications that rely on NetTcpBinding endpoints. Finally, the
default values for theListenBacklog and MaxConnections settings are
set to 10 which is far from optimal for a large number of clients.

Also note that without more information on what part of communication is timing out, it's difficult to say the exact cause. Remember, each side of the transaction has different timeout settings for Open, Close, and Send or Receive.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文