Thanks for your thoughts William. It helps to have some guidelines regarding
what a reasonable number of threads is, etc. I obviously haven't done a
great deal of multithreaded programming.
I'm comfortable with limiting the service to accepting 100 simultaneous
connections. A typical load on the server will be less than 1000 connections
per hour; each connection will pass (in one big lump) an average of 200 text
strings that will be looked up. If I go with a multithreaded approach my
current thought is that each thread will take one of these connections,
lookup values for each of the text strings, return all the values and at
that point terminate the connection (so yes, the reply indicates the end of
the session). The thread would then be put back into the thread pool for
reuse. All the table data (probably 300,000 rows) will stay in RAM so
lookups should be extremely quick.
I might be able to pull this off with a single threaded app but it seems
better to plan for future growth now. I haven't done any performance testing
yet but I can't imagine that the actual lookup process will take much time -
I'm guessing that most of the time will be occupied by making the connection
and transferring the data between the client and the server.
I'll have to study up on the response queue idea.
Again, thanks. You've given me plenty to think about.
------------------------------
"William Stacey [MVP]" <st***********@mvps.org> wrote in message
news:#R*************@TK2MSFTNGP12.phx.gbl...
100 threads should be not problem. Some use <= 1000 threads without issue
(however 1000 is pushing it imo.) You could fire up new threads upto to
some max, say 500, then block new requests with server busy reply. You
could also use your own thread pool (many existing example out there such as
Codeproject) with some max and have ready threads ready to go. These
servers are much easier to create and reason about. Async servers may scale
better, but are harder to code and get right and have the potential thread
pool blocking issue. If you have like 10,000 active requests, then async is
the option, but if you really have that many then the server will melt
anyway or be so slow that almost nothing gets done. So your back to
factoring out load between other servers - which you could do with either
approach. Therefore, the threaded server may start to look better again.
If your not blocking alot in your processing piece (i.e. just doing cached
table lookups) then potentially you could service all requests with *one*
thread using a queued approach. Queue up all requests and service the queue
with one tight server loop and send the reply. Your replies could be put
into yet another queue that is serviced by one-to-N threads (say your own
thread pool or the system thread pool) so that one reply can't block the
server. For that matter, your receiver side could be 1-N threads also that
waits for and builds the complete requests - so one slow client does not do
a DoS on your server. Each Client-Listener thread would put completed
request into the server IN-Q. The one server thread reads from IN-Q,
processes, and writes reply to OUT-Q. The Out thread pool handles the
socket sends and socket closing (UDP may work better for this single
request/reply deal). Even with TCP, this would work well for simple
request/reply where a reply signals the end of the session. I tend to favor
the threaded server or queued server approach (others may vary.) hth
--
William Stacey, MVP
http://mvp.support.microsoft.com
"Quiet Man" <qu******@mailinator.com> wrote in message
news:en**************@TK2MSFTNGP14.phx.gbl...
Hi all,
I'm designing a fairly simple service that will run on W2K/SP4 and W2K3
servers. It's job is to be a very specialized database server that listens
on a given IP address / TCP port and handles multiple connections. Client
programs will make a connection and pass text strings to the service,
which will then return a value for each of the strings. It's unlikely the
service will ever have more than 100 simultaneous connections and most of what it
will do is a lookup in a table for each string. We've considered MSDE for
this and for a number of reasons it's impractical for us to use it.
In researching various ways of handling simultaneous connections I've seen
examples using multithreading and others using async I/O. I'd like the
program to scale well but I don't want to overwhelm the server. I'm
looking for guidance on choosing between the two methods.
Alternately, I'd be happy to use a commercial database server if I could
find one that can be distributed easily and royalty free and which doesn't
cost too much. Something like the VistaDB database engine would be ideal
but it can't run as a service.
Thoughts / suggestions?