我需要一些帮助才能指出正确的方向。
我们希望通过WebHTTP端点公开服务功能（包括读取和更新SQL Server数据库），作为对用户的每次呼叫服务。 如果可以避免，我们不想使用SOAP，因为我们很难在其他平台上进行互操作。 这必须可扩展到1000多个用户，在这种情况下，这些用户不太可能提交许多并发请求。据估计，在任何给定时间应该有最多25个并发请求。
（这就是为什么会议服务被排除在外，因为这意味着要保持1000多个会话开放，而只执行25个行动。）
根据测试服务的经验，我们发现，使用HTTP上的纯Per-Call WCF服务表现不佳，最大的时间流逝是SQL服务器连接的初始化。
这与Web服务器通常会遇到的情况类似。 因此，使用与Web服务器类似的方法似乎是明智的 - 出于性能原因，它们使HTTP引擎池保持活动状态，并且传入的请求被分配给池中的一个引擎。
因此，我们希望保留一个25-30个“业务逻辑对象”池（即具有与纯服务接口分离的实际服务逻辑的类），这应该在服务主机启动时进行实例化。
似乎WCF没有内置的方案支持这种开箱即用。 我该怎么办呢？
当我自我托管时，我可以从ServiceHost派生一个自定义类，并添加一个包含Business对象的Dictionary。这会产生线程问题我想，我必须处理手动同步，对吗？
如果我们决定在IIS中托管，那我该怎么做呢，因为IIS自动负责创建ServiceHost类的实例，因此我没有太多机会在中间抛出我自己的自定义主机，是吗？
或者这是一个糟糕的方法。任何其他想法赞赏。
答案 0 :(得分：2)
实际上是否存在无状态，无会话方法的瓶颈？
“业务逻辑对象”池对我来说不是一个好主意。您将面临难以调试的并发问题。
您是否真的测试了以下模式？
根据测试服务的经验，我们发现使用纯粹的 通过HTTP的每个呼叫WCF服务执行得很差，时间最长 失败是SQL服务器连接的初始化。
实际上，由于SQL Server连接池，SQL Server连接不应该成为瓶颈。
答案 1 :(得分：0)
我不认为他们与实例化业务逻辑对象相关的成本太高。您可以在ken指向的SQL连接对象上启用池。最好去缓存业务对象而不是汇集业务逻辑对象。