2

我需要一些帮助来为我指明正确的方向。

我们希望通过 WebHTTP 端点向用户公开服务功能（包括读取 + 更新 SQL Server 数据库）作为每次调用服务。如果可以避免，我们不想使用 SOAP，因为我们很难在其他平台上实现互操作。这必须可扩展到 1000 多个用户，在这种情况下，这些用户不太可能提交许多并发请求。估计在任何给定时间最多应该有 25 个并发请求。

（这就是为什么每会话服务被排除的原因，因为这意味着保持 1000 多个会话打开，而只执行 25 个操作。）

然而，根据测试服务的经验，我们发现通过 HTTP 使用纯 Per-Call WCF 服务的性能很差，最大的时间间隔是 SQL 服务器连接的初始化。

这与 Web 服务器通常会遇到的情况类似。因此，使用与 Web 服务器类似的方法似乎是明智的——出于性能原因，它们保持 HTTP 引擎池处于活动状态，并且传入请求被分配到池中的引擎之一。

因此，我们希望保持 25-30 个“业务逻辑对象”（即具有与单纯的服务接口分离的实际服务逻辑的类）的池打开，它应该在服务主机启动时被实例化。

似乎 WCF 没有内置的场景来支持这个开箱即用。我该怎么办？

当我是自托管时，我可以从 ServiceHost 派生一个自定义类并添加一个带有业务对象的字典。我猜这会导致线程问题，我必须通过手动同步来处理，对吗？

如果我们决定在 IIS 中托管，那么我将如何做呢，因为 IIS 会自动负责创建 ServiceHost 类的实例，因此我没有太多机会在​​两者之间放置我自己的自定义主机，是吗？ ?

或者这完全是一个不好的方法。任何其他想法表示赞赏。

4

2 回答 2

2

无状态、无会话的方法实际上是否存在瓶颈？

“业务逻辑对象”池对我来说不是一个好主意。您将面临难以调试的并发问题。

您是否实际测试过以下模式？

  • 每个请求一个业务逻辑对象，尽可能短的生命周期
  • 每个业务逻辑对象一个 SQL 连接
  • 无状态服务

然而，根据测试服务的经验，我们发现通过 HTTP 使用纯 Per-Call WCF 服务的性能很差，最大的时间间隔是 SQL 服务器连接的初始化。

实际上，由于 SQL Server 连接池，SQL Server 连接不应该成为瓶颈。

于 2012-07-01T19:47:20.990 回答
0

我认为它们与实例化业务逻辑对象相关的成本不会很高。您可以在 ken 指出的 sql 连接对象上启用池。最好去缓存业务对象而不是池化业务逻辑对象。

于 2012-07-02T06:39:22.147 回答