thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Utku Can Topçu <u...@topcu.gen.tr>
Subject Re: Java Server Does Not Close Sockets immediately for oneway methods
Date Thu, 11 Feb 2010 18:58:47 GMT
Ted,

I think you're mixing my proposed strategy which is employing another
ThreadPoolExecutor other than the Thrift framework offers, and the current
late close strategy. That 90K calculation is a production load calculation
and I truly observed it in a few minutes.

Can you please briefly explain your objection again?

Regards,
Utku

On Thu, Feb 11, 2010 at 8:42 PM, Ted Dunning <ted.dunning@gmail.com> wrote:

> If you have 500 requests per second and a ThreadPoolExecutor with 500
> threads and you have > 1 second average completion time for each request,
> then open sockets will be the least of your problems since you will be
> queuing requests ahead of the ThreadPoolExecutor.  With 4 seconds per
> request, you need at least 4 x 500 threads to properly service your volume.
>
> If you have a sufficient number of threads then you will probably only have
> about 2000 sockets open even with the current late close strategy.
>
> On Thu, Feb 11, 2010 at 10:05 AM, Utku Can Topçu <utku@topcu.gen.tr>
> wrote:
>
> > In our production load, we have ~500 oneway requests per second in peek
> > time. Say each request needs 4 seconds to complete in 500 concurrency.
> > The client side successfully makes the request and closes it's
> connection.
> > If we face a peek period more than 3-4 minutes the number open
> connections
> > exceeds the number of connections allowed by the Operating System.
> > 4*60*500 = 120000 socket connections in 4 minutes
> > ((4*60)/4)*500 = 30000 requests processed in 4 minutes
> > 120000 - 30000 = 90000 open connections afer 4 minutes of peek time
> >
>
>
>
> --
> Ted Dunning, CTO
> DeepDyve
>

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