WCF 命名管道服务设置
使用命名管道时是否值得使用 ConcurrencyMode.Multiple 和 InstanceContextMode.Single 属性设置服务来节省一些性能？
我的意思是，当我这样做时，我必须担心多线程问题。
Is it worth to set the service with ConcurrencyMode.Multiple and InstanceContextMode.Single attributes to save some performance when using named pipes ?
I mean when I do so I have to bother with multithreading issues.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我自动对 WCF 服务使用 ConcurrencyMode.Multiple，因为我通常希望服务能够同时处理多个请求。对我来说，这似乎是服务最直观的行为（即：如果我调用 Web 服务并且必须等待其他用户的 10 个未完成的请求才能得到处理，那会很奇怪）。
使用 ConcurrencyMode.Single 强制服务一次处理单个请求（如果有多个请求，它们将排队）。这可能会减慢请求速度。
但这取决于每个请求的作用。简单的数学计算或字符串操作将会非常快，以至于 WCF 的开销将成为您的主要瓶颈。如果您的服务查询或修改某种数据库，则执行数据库操作的时间可能是您的瓶颈。但如果数据库很小，或者您只期望少量的客户端，您可能永远不会注意到其中的差异。如果您从 5 个 Web 服务中提取数据并执行一些复杂的合并操作，这可能是一个问题。
除非您知道将有多个并发请求，否则请使用 ConcurrencyMode.Single 运行，直到无法满足某种客观性能标准。然后，您需要进行通常的基准测试，以确定服务的哪一部分最慢。加快一点速度。如果 ConcurrencyMode.Single 速度较慢，请改为使用 Multiple！
I automatically use ConcurrencyMode.Multiple for my WCF services, because I normally expect a service to be able to handle multiple requests at the same time. To me, this seems like the most intuitive behaviour for a service (ie: it would be strange if I called a web service and had to wait for 10 outstanding requests from other users before I was attended to).
Using ConcurrencyMode.Single forces the service to process a single request at a time (in the event of multiple requests they are queued). This, potentially, will slow requests down.
But it depends on what each request does. Simple math calculations or string manipulations going to be so fast that the overhead of WCF will be your main bottleneck. If your service queries or modifies some sort of database, the time to do the database operation is likely to be your bottleneck. But if the database is small, or your only expecting a small number of clients, you'll probably never notice the difference. If you're pulling data from 5 web services and doing some complex merging operations, this might be a problem.
Unless you know you'll have multiple simultaneous requests, run with ConcurrencyMode.Single until some sort of objective performance criteria cannot be met. Then, you'll need to do the usual benchmarking to figure out what part of your service is the slowest. Speed that bit up. If it happens that ConcurrencyMode.Single is the slow bit, go for multiple instead!
值得吗？这取决于与实施难度相比，您对性能提升的重视程度。
性能增益有多好？这取决于应用程序。只有您可以通过测量来回答这个问题。
与往常一样，对于性能，您必须衡量。
如果它已经够快了，就不用担心了。
如果速度不够快，请测量应用程序将时间花在哪里。在大多数涉及进程外资源访问（例如数据库访问）的应用程序中，瓶颈就在这里，而不是在WCF 服务的InstanceContextMode 中。
但是，您没有编写 WCF 服务是什么类型的应用程序，因此它可能会对您的情况产生影响。
Is it worth it? That depends on how much you value the performance gain, compared to how difficult it is to implement.
How good is the performance gain? That depends on the application. Only you can answer that question by measuring.
As always with performance, you must measure.
If it's fast enough already, don't bother.
If it isn't fast enough, measure where the application spends its time. In most applications that involve out-of-process resource access (e.g. database access), the bottleneck is here, rather than in a WCF service's InstanceContextMode.
However, you don't write what kind of application is your WCF service, so it may make a difference in your case.