thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Jiang <sji...@apache.org>
Subject Re: using acceptQueueSizePerThread with TThreadedSelectorServer in java
Date Fri, 13 Sep 2013 20:29:18 GMT
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.
> 

Mime
View raw message