工作在无状态的WCF休息Web服务上，并具有3个独立任务的操作。每一个都可以独立运行。每个任务都包含对外部API的Web服务调用，后续的本地数据库读取操作的时间少于0.25秒。WCF多线程与可伸缩性考虑
首先想到的是，我应该产生3个单独的线程，然后加入并返回结果。使用线程池在这里可能不是一个好主意，因为它限制在250个最大值之内。
性能值得关注，但不以牺牲可扩展性为代价。
我应该关心启动&为每个Web服务调用加入3个单独的线程的开销吗？
将对外部服务的调用封装到异步任务方法中，然后从您的WCF方法调用。它将使用线程池，并在线程拉伸耗尽时将您的Web服务调用很好地排队。
您可以使用异步IO来执行web服务调用。异步IO在运行时不会占用任何线程。你可以为数据库调用做同样的事情。这可以缓解您可能遇到的任何线程问题。
或者，您可以依赖线程池。你可以增加限制。你可以计算你需要多少个线程：如果每秒有100个请求到达，每个请求需要2秒才能完成，你需要200个线程。假设您配置了适当的限制，这可以通过内置线程池轻松实现。
如果外部服务中断并需要30秒超时，此数字现在可以拍摄多达3000个线程，我认为这些线程是不安全的。所以你要么需要一个很低的超时时间，断路器或异步IO。
所以为了决定你需要预测负载和延迟。
我会链接到一些讨论为什么以及何时异步IO使用：
https://stackoverflow.com/a/25087273/122718为什么EF 6教程中使用台异步调用？ https://stackoverflow.com/a/12796711/122718我们是否应该默认切换到使用异步I/O？
但是，这将违背可扩展性要求。线程池最多限制为250个线程。 – AlexVPerl
线程池大小通常等于逻辑线程数乘以25.为了扩展您的服务，您需要不断增加服务可用的逻辑线程数。 –
我不认为ThreadPool适合我的问题，由于线程数限制。我甚至不会考虑使用ThreadPool。直接使用线程，不会强加任何软限制，只是您的硬件可以支持。 – AlexVPerl