异步远程调用
我们有一个在单独的 Windows 服务中运行的远程单例服务器（我们称之为 RemotingService）。 RemotingService 的客户端是 ASP.NET 实例（很多很多）。
目前，客户端远程调用 RemotingService 并在为 RemotingService 调用提供服务时阻塞。 然而，远程处理服务变得足够复杂（有更多的 RPC 调用和复杂的算法），导致 ASP.NET 工作线程被阻塞相当长的时间（4-5 秒）。
根据 这篇 msdn 文章，这样做不会很好地扩展，因为 asp每个远程 RPC 的 .net 工作线程都会被阻止。 它建议切换到异步处理程序以释放 ASP.NET 工作线程。
异步处理程序的用途 就是释放一个ASP.NET线程池 线程来服务额外的请求 当处理程序正在处理 原始请求。
这看起来很好，只是远程调用仍然占用线程池中的一个线程。 这是与 asp.net 工作线程相同的线程池吗？
我应该如何将我的远程处理单例服务器转变为异步系统，以便释放我的 ASP.NET 工作线程？
我可能错过了一些重要信息，如果有，请告诉我您需要了解的任何其他信息才能回答该问题。
We have a remoting singleton server running in a separate windows service (let's call her RemotingService). The clients of the RemotingService are ASP.NET instances (many many).
Currently, the clients remoting call RemotingService and blocks while the RemotingService call is serviced. However, the remoting service is getting complicated enough (with more RPC calls and complex algorithms) that the asp.net worker threads are blocked for a significantly long time (4-5 seconds).
According to this msdn article, doing this will not scale well because an asp.net worker thread is blocked for each remoting RPC. It advises switching to async handlers to free up asp.net worker threads.
The purpose of an asynchronous handler
is to free up an ASP.NET thread pool
thread to service additional requests
while the handler is processing the
original request.
This seems fine, except the remoting call still takes up a thread from the thread pool.
Is this the same thread pool as the asp.net worker threads?
How should I go about turning my remoting singleton server into an async system such that I free up my asp.net worker threads?
I've probably missed out some important information, please let me know if there is anything else you need to know to answer the question.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
使用 ThreadPool 背后的想法是，通过它您可以控制同步线程的数量，如果同步线程数量太多，那么线程池会自动管理新线程的等待。
Asp.Net 工作线程 (AFAIK) 不是来自线程池，也不应该受到您对远程服务的调用的影响（除非这是一个非常慢的处理器，并且您的远程功能非常占用 CPU 资源 - 其中这种情况下，您计算机上的所有内容都会受到影响）。
您始终可以在不同的物理服务器上托管远程处理服务。 在这种情况下，您的 asp.net 工作线程将完全独立于您的远程调用（如果远程调用是在单独的线程上调用的）。
The idea behind using the ThreadPool is that through it you can control the amount of synchronous threads, and if those get too many, then the thread pool automatically manages the waiting of newer threads.
The Asp.Net worked thread (AFAIK) doesn't come from the Thread Pool and shouldn't get affected by your call to the remoting service (unless this is a very slow processor, and your remoting function is very CPU intensive - in which case, everything on your computer will be affected).
You could always host the remoting service on a different physical server. In that case, your asp.net worker thread will be totally independent of your remoting call (if the remoting call is called on a separate thread that is).