Rajneesh kapur wrote, on 9/13/13 11:42 AM:
Hi,
Can someone please help me understand the following thing:
1) what is difference between selector threads and worker threads. How can
I limit client not to flood server with lots of requests?
Selector threads handle reading/writing requests and responses to the
client. Worker threads run your thrift interface methods. If your
problem is with new connections, you can limit acceptQueueSizePerThread.
For existing connections there's currently no backpressure policy.
You'd need to modify the server to drop existing connections if your
threadpool is too busy.
2) I am using TThreadedSelectorServer with (selector 4 and workers = 10)
When a client sends 20 concurrent requests then first 10 responses takes
almost the same time as time spent on server side. However the rest of the
10 threads
(11..20)take lot more. If I increase the worker threads on server side to
50 - and client sends 100 requests then again same behavior. First 50 takes
same amount of time as serverside and next 50 takes take lot more time but
on server side inside the handler its similar for all 100 threads.
Why on client side 51..100 threads response takes so much time? are these
threads waiting on server side to get their chance to run? If so how can I
set a limit that beyond some number we will not accept connections on
server side?
Sounds like your workload is blocking and not bottlenecked by network
events. TThreadedSelectorServer probably does not provide an advantage
in this case over threadpool or hsha server.
I tried with acceptQueueSizePerThread, and
args.acceptPolicy(AcceptPolicy.FAIR_ACCEPT); but on client side I don't see
any exceptions. Is this right thing to do?
thanks a lot,
-raj.
