I'd strongly caution you on building this application for specific hardware. You'd be better off allowing, for example, a command line argument to tune the application.
How many simultaneous connections do you expect? I've written a Java server that spawned a thread per connection and it was able to handle a few thousand connections on pretty lowly hardware. However, you're correct that it realistically won't scale into the 10's or 100's of thousands.
My suggestion is to have a configurable thread pool size. As connections come in you will assign a thread to them. Then, once your worker pool is exhasted, start kicking off clients using a least recently used rule. That is, you'll have a connection class of some sort that will have a timestamp of when the last activity happened on the connection. When your thread pool is exhausted you'll walk the pool somehow and find the oldest connection and close it, freeing that thread for more work.
Basically this is a combination of a thread pool and a thread per connection. If you have a modest number of clients then they each get a dedicated thread, improving response time. As the number increases you trade off some performance for scalability. Of course your client code will have to be able to handle being shutdown and re-initilize the connection as needed.
Also, remember that on most operating systems there are limits as to how many connections you can have at the same time. For example, on some Unix systems you would only be able to have some number less than 1024. Windows has similar restrictions.
Start out with a default pool size of, say, 64. Don't allow the command line argument to increase it past that allowed by your O/S.
Just some quick thoughts.
Quote:
|
Originally Posted by Alfarin
Hi all,
Just wondering if anyone knwo what the ideal thread count for an multithreading application should be? I am trying to code a server client based application which would have to handle mutliple connections at a time. From what I read, for medimum sized application, it'd be good to create on thread per connection; however, on larger applications, it would be impossible to do so and is usually suggested to use "thread pools". I want to make my application capable of handeling as much "stress" as possible, so I'd assume that thread pool would be the way to go; but I don't know how much threads I should make for the pool size. Does any one have suggestions as to how many threads I should allocate for thread pool for single application for a server application? I'm thinking for now that I may be running this on a 800MHz server with roughly 512 MB of ram (if this is of any significance to the calculation to how many threads I should use).
Regards,
Andy Huang
|
Linear Mode
