WCF 自托管性能
我正在使用 WCF 和 NetTCP 服务编写企业级应用程序。 我最初出于好奇而选择了 NetTCP，但后来确定它对我来说是最佳选择，因为由于涉及大量数据处理，我可以调用需要 5 个多小时才能返回结果的服务。
我目前生成服务的方式是一个多步骤的过程。 我有一个配置块（使用 System.Configuration），它指定一些默认内容（端口号、连接客户端的服务器名称、是否启用 HTTP 以及 NetTCP 等），并且下面有一组“服务”它。 例如，基本的情况如下：
<serverConfiguration tcpListenerPortNumber="60000" httpGetEnabled="true" httpListenerPortNumber="6000" serverName="localhost" retryEnabled="true" retryInterval="5" maxRetryAttempts="3">
<services>
<add virtualDirectory="Service1" applicationName="Service1" assembly="SampleService" type="SampleService.Service1" />
</services>
</serverConfiguration>
基本上，这里发生的情况是我的 Windows 服务启动并查看
我遇到的“问题”是该应用程序托管大约 20 个服务，所有服务启动并运行需要 15-20 秒的时间。 我做了线程和 AppDomain 部分以将其降低到该值（过去需要花费一分钟多的时间，因为每个服务都是按顺序打开的），但在我看来，这实际上可以快得多。
有人有什么建议吗？ Google Bing 有大量托管一项服务的示例，但我没有找到太多用于实际应用程序的示例（遗憾的是“Hello World”对最终用户没有吸引力）。 如果您当前通过 Windows 服务和 NetTCP 托管多个服务，您是如何做到的？
I am in the process of writing an enterprise-level application utilizing WCF and NetTCP services. I chose NetTCP initially out of curiosity, but later determined it to be the best option for me since I can have services that are called that take 5+ hours to return results due to the amount of data crunching involved.
The way I currently spawn my services is a multi-step process. I have a configuration piece (using System.Configuration) that specifies some of the default stuff (port number, server name for clients connecting in, whether to enable HTTP as well as NetTCP, etc) and that has a collection of "services" underneath it. For example, here's what a basic one looks like:
<serverConfiguration tcpListenerPortNumber="60000" httpGetEnabled="true" httpListenerPortNumber="6000" serverName="localhost" retryEnabled="true" retryInterval="5" maxRetryAttempts="3">
<services>
<add virtualDirectory="Service1" applicationName="Service1" assembly="SampleService" type="SampleService.Service1" />
</services>
</serverConfiguration>
Basically what's happening here is my Windows service kicks off and looks at everything in the <services /> collection and spawns off a thread per service to speed startup time and each thread contains an AppDomain where the service truly lives so if a service has some kind of fault it doesn't bring the system down.
The "problem" I am running into is this application is hosting approximately 20 services and it takes a good 15-20 seconds for all the services to be up and running. I did the threading and AppDomain pieces to get it down to that value (used to take over a minute as each service was opened sequentially) but it still seems to me that this could actually go a lot faster.
Anyone have any suggestions? Google Bing has a plethora of examples for hosting one service but I'm not finding much out there for real-world applications (sadly "Hello World" just isn't appealing to end users). If you're currently hosting multiple services via a Windows Service and NetTCP, how are you doing it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我终于弄清楚了，它毕竟与 WCF 或我的配置部分无关。 当我创建 AppDomain 时，我从我们拥有的另一个项目中窃取了代码，该项目的大小要小得多，并发现创建 AppDomain 的部分正在使用 SingleDomain 选项。 将其更改为多域使总负载时间超过 4 秒，内存使用量从约 150MB 降至约 40MB。
不过还是感谢您的帮助 - 至少它让我再次审查了代码！
I figured it out finally and it had nothing to do with WCF or my configuration pieces after all. When I was creating the AppDomain I stole the code from another project we had that was much smaller in size and found that the section creating AppDomains was using the SingleDomain option. Changing it to MultiDomain made things go to >4 seconds for total load and memory usage dropped to ~40MB from ~150MB.
Thanks for the assistance though - at least it got me reviewing the code again!
我有三个建议：
首先，如果一个呼叫可能需要 5 个多小时，我会考虑排队/回调式架构。
考虑将您的服务拆分为 20 个 Windows 服务，其中每个服务都在其自己的 Windows 服务中运行。 这增加了复杂性并增加了内存使用量，但单个服务可能会更快可用。
最后，检查服务构造函数中的代码是否有任何不需要的代码。
I have three suggestions:
Firstly, if a call can take 5+ hours, I would consider a queuing / call back style architecture.
Consider splitting your services into 20 windows services, where each service runs in it's own windows services. This adds complexity and increases memory usage, but an individual service may be available faster.
Lastly, check the code that is in the consructor of the service, for any unneeded code.