WCF 性能：我可以像 ConnectionPooling 那样创建对象池吗
我有一项服务使用相当昂贵的对象来创建。我想提高每次通话的性能。
当我删除对象并运行负载测试时，例如每秒可以执行多少次调用，不同情况之间的性能差异巨大。
情况 1. 我删除了昂贵的对象：每秒调用次数 ~= 130。 情况 2. 我照常使用它，目标是：速率为 ~= 2 每秒。
我有一个托管在 IIS 2008 服务器上的 .NET WCF 服务。
我想知道是否有一种方法可以创建对象缓存/池并将这些对象传递给服务的每次调用。
有什么想法/评论可以帮助这种情况吗？
I have a service that uses a fairly expensive object to create. I would like to improve the performance from call to call.
When I remove the object and run a load test, like how many invocations I can do per second, I have a massive performance difference between to situations.
Situation 1. I remove the expensive object: Invocations per sec ~= 130.
Situation 2. I use it as normal, with the object: rate is ~= 2 per sec.
I have a .NET WCF service hosted on an IIS 2008 server.
I was wondering if there was a way I could create an object cache/pool and hand those objects to each invocation of the service.
Any thoughs/comments that may help this situation?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以在每个会话模式下运行 WCF 服务，并使用单例模式创建对象，这样每个会话只需创建一次对象，而不是每次调用创建一次对象。
您还可以使用企业库缓存来缓存对象。
You could run the WCF service in per session mode and create the object using the singleton pattern, that way you only create the object once per session, as opposed to once per call.
You may also be able to cache the objects using enterprise libray caching.
如果昂贵的部分是构建对象的状态，并且您只想限制创建该对象的次数，我建议使用持久服务。
持久 WCF 组件在调用之间和客户端之间保留其状态。每次调用方法时，它都会将其状态写入持久性存储（默认为 SQL Server 数据库）。问题是您必须在要调用持久组件的人之间传递上下文令牌。该令牌可以保存在文件或数据库等中。
这将允许您对组件进行调用，它可以创建一次其状态，然后您可以继续从其他客户端调用它，只要它们有权访问其上下文令牌即可。
由于每次客户端关闭时对象都会消失，因此内存中没有任何内容挂起，但状态仍然存在。
这是教程。
If the expensive part is building the State of the object, and you only want to limit the number of times that you create that object, I suggest using a Durable Service.
A Durable WCF component persists its state between calls and between clients. Each time you call a method it writes its state to a persistence store (the default is a sql server database). The catch is you have to pass around a context token between whoever is going to call your Durable component. This token could be persisted in a file or database or whatever.
This would allow you to make a call against the component, it could create its state one time and then you could keep calling it from other clients as long as they have access to its context token.
Nothing hangs around in memory since the object goes away each time your client closes, but the state persists.
Here's a tutorial.