Hi,
I'm developing an application that will support several thousand
simultaneous connections on the server-side. I'm trying to maximize
throughput. The client (WinForms) and server communicate via a socket
connection (no remoting, no ASP.NET). The client sends a message to the
server that contains some instructions and the server responds in an
asynchronous fashion. In other words, the client doesn't block while waiting
for the request. The request might be processed on the server in a split
second or it might take a few minutes. In any case, the client doesn't wait
around for the response. It happily goes about servicing the user and when
the server gets around to responding, the client makes that response data
available to the user.
Now let's look at what's happening on the server. The server basically
receives a message from the client on an I/O thread-pool thread and does as
much as it can to process that request. Sometimes the server logic realizes
that it must talk to another server to process the request. In that case,
the thread-pool thread on the server does NOT block. It simply sends it's
request asynchronously to another server and then the thread returns to the
pool. When the secondary server does its thing, it'll notify the main server
via an existing socket connection, an I/O thread from the .NET thread pool
is assigned the task of reading this information, and this thread eventually
sends the results back to the client. Again, my desire is to eliminate
thread-blocking on the server whenever possible since thread-pool threads
are a limited resource (25/CPU, I believe). Make sense so far? ok...
...but now I'm in a bit of a pickle [not literally, that's just an
expression]. I'm now required to have the server respond to a certain type
of client request that requires that a SQL Server database be contacted. The
request might call for a SELECT statement or INSERT/UPDATE/DELETE or for a
stored proc to be executed. So I thought "no problem" -- I'll just use
ADO.NET. The problem though is that ADO.NET is synchronous and "blocking" by
nature. There is no "BeginFill( )" for example to asynchronously fill a
DataSet. What are the implications of this? Well, for starters, this means
that whenever my server is waiting for a reply from ADO.NET, the thread-pool
thread that is making the call just blocks. This might not sound like such a
big deal but on a two CPU machine that has 50 threads in the pool, I could
easily encounter a situation where all 50 threads are blocked waiting for
ADO.NET responses -- which means that there are no threads left to process
incoming requests. Even *simple* requests that don't require database access
must sit grudgingly in the queue because all of the thread-pool threads are
sitting idly in a blocked state waiting for ADO.NET calls to return! Not
good!
Now you might say, "Listen, brother...Just use delegates and
BeginInvoke() to simulate asynchronous behavior for your database calls."
This won't work because of course BeginInvoke() simply will place the call
in the thread pool queue and then make the call synchronously. You might
say, "My friend... Use the .NET API command that increases the number of
threads in the pool." This doesn't solve the problem though and it's hackish
and it implies that I know better than MSFT how many threads should be in
the pool [which I don't].
What other approach might I take? Perhaps I should create a bunch of
threads manually and use these for database access? It's ugly, but at least
I'm not wasting my valuable thread pool threads which are used for
processing of incoming requests.
I'm going to give MSFT the benefit of the doubt that they made ADO.NET a
synchronous blocking animal for good reason... and they're right, I suppose,
because 99% of the time it makes sense to make ADO.NET calls in a
synchronous fashion. But in my case, hopefully you'll see my plight and have
a clever workaround for me!
Peace be with you!
David
