调整WCF文件服务器

我正在调整服务器，需要一些指导。此服务器提供以下功能：

一个带有DB调用的ASPX页面，几千台机器大约每3分钟下载一次

一个简单的ASP.NET管理网站，只供少数人使用，但必须具有高可用性

一种WCF服务，使用BasicHttpBinding和流式消息向其他数千个客户端提供文件同步

当文件同步客户端（#3）可以使用更新时，它们会蜂拥到服务器上，争相获取新数据。如果不进行积极的节流，它们会耗尽所有可用的ASP.NET工作线程，并导致#1和#2挂起。就像孩子们说的，这是sux0rs

我在4-proc服务器上重现了这个问题。当一个测试客户端同时创建100个下载时，我看到48个下载同时运行；在perfmon中，我看到其余部分在ASP.NET->应用程序队列中的请求中排队。这与描述的“每个CPU 12个并发线程”默认设置相匹配。CPU和内存看起来不错；它实际上只是在不进行处理的情况下传递字节

在我看来，有几件事我可以做，可能是协调一致

在machine.config中启动maxIOThreads和maxWorkerThreads

建立一个网络花园

重做客户端，以便直接处理下载，而不是通过WCF（例如，直接链接到文件，而不是通过消息流传输）

我的问题是:

• 除了试错之外，如果每个线程都将在CPU/内存使用率较低的情况下使用相当长的时间，那么增加线程数量的好准则是什么？如果我这样做，我如何确保增加的线程数的任务切换不会压倒系统并导致更多问题
• 在这种情况下，网络花园会有帮助吗
• 如果我从WCF下载并让IIS完全处理它，我会看到更好的性能吗

---

最好，roufamatic

做得好，WCF是完成这项工作的最佳工具。如果您要发送一个静态文件，我建议您查看一个异步服务impl（如果您想在ASP.NET中不使用WCF的话，可以查看一个异步HttpHandler），它构建在一个设置了异步标志的文件流上，并执行客户端的异步写操作。这将允许您更有效地使用工作线程，并将工作卸载到操作系统上。如果impl操作正确，同时下载同一文件的1000份副本不应导致您的服务器目瞪口呆。

好的，我被难住了。如果所有这些客户端都来到服务器请求它们的文件，那么请求是同步还是异步又有什么关系呢？最终，服务器必须连接到客户机并发送数据，当文件很大（实际上是这样）时，发送并吃掉进程中的线程需要很长时间。如果服务器正在做一些长时间运行的事情，我可以理解这一点，但实际上是客户端在做慢动作。在同步模式下，每个客户端有一个线程在缓冲区读/写时被阻塞，这会导致调度程序频繁地四处走动并唤醒它们，通常只会浪费希望缓冲区写入完成的时间片。一旦发生了大约20-30次这样的情况，执行线程状态恢复的时间就比实际工作要多。当您使用内核异步原语卸载读/写操作时，IOCP使用一个非常轻量级的调度器和h/w中断来服务缓冲区，并且仅在缓冲区准备就绪时分配和触发工作线程。更少的线程==完成更多的工作。重要的部分是在读取和写入时使用异步原语（从FileStream Open w/async FileOption设置读取，并将服务实现为Begin/End with AsyncPattern=true），并将Begin/EndRead和Begin/EndWrite与回调一起使用。否则，您只是在转移问题。客户端可以继续以“外观同步”的方式调用该方法。如果您以前从未实现过这种模式（这是一种“乒乓回调”方式），那么这种模式可能会有点复杂，但它将大大提高您在这种情况下的吞吐量。感谢您的回复。现在，同步调用返回一个MessageContract，其中一些数据指定为头，文件数据指定为正文中的流（如下所述：）。这个模式能适应您所描述的吗？或者我需要创建一个新的返回文件流的操作吗？是的，这很好（我也是这样做的）。如果不修改文件，可以将使用FileOptions.Asynchronous打开的文件流交给响应对象的流成员—仅此一点就可以解决问题（例如，可能不需要OperationContract上的AsynchPattern装饰，因为流的实际消耗是在操作返回后完成的）。我相信这一切都是隐藏的异步——同步操作使用了一个你看不到的阻塞包装器。我也不知道ASP.NET主机是否会改变这些，因为我总是自己托管。祝你好运