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 <[email protected]> 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 <[email protected]> > 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 >
