Thanks for your reply. So are the open HTTP connections that use my web
application code waiting in line to be processed by the available threads
specified in maxThreads?

Best,
John


On Sun, Mar 9, 2014 at 12:44 PM, Konstantin Kolinko
<knst.koli...@gmail.com>wrote:

> 2014-03-09 2:08 GMT+04:00 John Smith <tomcat.ran...@gmail.com>:
> > Sorry, forgot: Tomcat 7.0.42
> >
> >
> > On Fri, Mar 7, 2014 at 3:59 PM, John Smith <tomcat.ran...@gmail.com>
> wrote:
> >
> >> The NIO connector has two attributes from the standard HTTP Connector
> >> implementation, maxConnections and maxThreads with defaults of 10000 and
> >> 200, respectively.
> >>
> >> Can anyone shine some light on how these work together? If I'm allowing
> up
> >> to 10000 connections, would that mean I only have 200 threads to process
> >> through them? It would seem to be a disparity between the defaults. If
> I'm
> >> expecting maxConnection numbers in the area of ~2000 at any given time,
> >> wouldn't I want to bump up my maxThreads closer to match that?
> >>
> >> Production environment is:
> >>
> >> DELL PowerEdge R720
> >> Single Socket Six Core Intel Xeon E5-2640 2.5GHz
> >> 32 GB RAM
> >> RHEL 6
> >>
>
> Roughly speaking,
>
> The new APIs in java NIO and in Apache APR (and ultimately in
> underlying OS) allow to test whether there are incoming data on a
> network socket without actually reading it.
>
> A thread is needed when Tomcat calls your code in a web application to
> process a request.
>
> When request processing ends and control is returned to Tomcat, the
> request processing thread is decoupled from connection and is used to
> process other connections.  With keep-alive feature in HTTP/1.1
> protocol there may be several HTTP requests on the same HTTP
> connection,
>
> maxConnections = how many open HTTP connection can be hold by Tomcat
> maxThreads = how many requests are being actively processed at the same
> time.
>
> Best regards,
> Konstantin Kolinko
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Reply via email to