Monday, July 9, 2012

Thrift TThreadedPoolServer thread pool

Don't know how many of you are still using Thrift - it's still going strong here because it works so much better than RMI.

Just a small tip, I recently came across a TThreadedPoolServer. The idea is that a thread pool gets used to serve requests from the clients - so each client has its own thread. In my opinion, this is not ideal, but this is how it's working at the moment.

There is a danger though: make sure you set the maximum number of threads in the pool! Otherwise it just keeps on adding threads to the pool - returning them I don't know when. The app was sitting at 400+ threads just now.

It's easy to do:

You can of course set a minimum etc. as well. I'm not sure when the threads are "freed" and returned to the pool - I'll investigate this later today.

8 comments:

  1. Your "maxWorkerThreads" should probably match the System.getRuntime().getAvalableProcessors()

    ReplyDelete
  2. It should be the # of concurrent clients I'm willing to accept no? Remember, I'm the server...

    I think you actually want to rather use the TNonBlockingServer. This use non-blocking IO in a single thread to handle multiple connections, ala nginx and more advanced servers these days.

    ReplyDelete
  3. Yes - If the number of threads increases beyond what you can process, you'll have fun with thread context switching. The NIO approach obviously scales much, much better.

    ReplyDelete
  4. Oh threading... thou are a heartless bi... " belligerent, unreasonable, rudely intrusive or aggressive person of the female gender". 

    The number of threads should not always the same as the available processors.  The number of actively running threads should be equal to the number of available processors.  If threads are blocking, more threads are of course advisable.

    ReplyDelete
  5. If you are still using the "old way" and not NIO (non-blocking), you have bigger issues than just the usage of threads. Simple fact: the "old way" doesn't scale.

    Node.js (even though I *hate* to use it as an example) is an example of how the non-blocking scheme scales.

    ReplyDelete
  6. I know of someone who would disagree with djoe there!

    ReplyDelete
  7. It really is scary how well node.js scales. It outperformed Jetty in a very simple, one time test (so this is by no means authoritative) I did on simple, static files.

    Considering it runs in an inherently single threaded environment, thats quite an accomplishment and an indication of how well NIO can scale.

    As far as I know, it was one of the driving forces behind nginx as well. Although Apache has improved, much of its core is still designed around the one-thread-per-request model, whereas nginx was built from the ground up as a non-blocking server.

    ReplyDelete
  8. Wiehann MatthysenJuly 9, 2012 at 3:33 PM

    NIO ftw! Btw. I think Jetty has NIO now as well. As far as I can remember you get the NIO functionality by just using a different constructor or something. 

    ReplyDelete