thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajneesh kapur <kapur....@gmail.com>
Subject Re: using acceptQueueSizePerThread with TThreadedSelectorServer in java
Date Mon, 16 Sep 2013 13:19:01 GMT
Thanks a lot for a quick response.

-regards,
-raj.


On Fri, Sep 13, 2013 at 4:29 PM, Steve Jiang <sjiang@apache.org> 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.
>>
>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message