Thanks a lot for a quick response. -regards, -raj.
On Fri, Sep 13, 2013 at 4:29 PM, Steve Jiang <[email protected]> wrote: > 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. >> >>
