Return-Path: X-Original-To: apmail-tomcat-users-archive@www.apache.org Delivered-To: apmail-tomcat-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 398F611ACF for ; Fri, 11 Jul 2014 17:07:23 +0000 (UTC) Received: (qmail 45736 invoked by uid 500); 11 Jul 2014 17:07:20 -0000 Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org Received: (qmail 45662 invoked by uid 500); 11 Jul 2014 17:07:20 -0000 Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Users List" Delivered-To: mailing list users@tomcat.apache.org Received: (qmail 45651 invoked by uid 99); 11 Jul 2014 17:07:20 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 11 Jul 2014 17:07:20 +0000 X-ASF-Spam-Status: No, hits=0.7 required=5.0 tests=RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [76.96.59.212] (HELO qmta14.westchester.pa.mail.comcast.net) (76.96.59.212) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 11 Jul 2014 17:07:15 +0000 Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta14.westchester.pa.mail.comcast.net with comcast id R4B01o0031HzFnQ5E56uJh; Fri, 11 Jul 2014 17:06:54 +0000 Received: from Christophers-MacBook-Pro.local ([68.55.8.89]) by omta14.westchester.pa.mail.comcast.net with comcast id R56t1o01A1vFKdg3a56uzs; Fri, 11 Jul 2014 17:06:54 +0000 Message-ID: <53C019AD.4040203@christopherschultz.net> Date: Fri, 11 Jul 2014 13:06:53 -0400 From: Christopher Schultz User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tomcat Users List Subject: Re: VERY HIGH TRAFFIC TUNING References: <53BE9EA4.50508@christopherschultz.net> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405098414; bh=kio2+rhn0eF8DJexPQV0RGb/UKujCm9BQnleqN8J2Y0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=KcC4Y9QKfwkwvOng8owzcA8c50+uDVaeJyG6JekNv4VrOHVLBncAgDS7VwT2fMele fY6fgjIhjf/75DFFq5hI+nw9JCGeu8RDfr5UH3FzGSK0RRceWLwf8J3/D1cxh3XiNr GfQ4QeabQR4ODufjnaoC7k9pC6LEZCRq0AfMVSTSmdbfzryLw1tAjxKnmzNiSy4/kA QJ6Yyxw+2LUXcjXMfJpWlVMvnLQJuB+lAwWMz8Nb9jxZRnYbIMv2au4/snJNy7WCC2 d8WDrwDoJNhRBxplPZeIczXzt+Ly2dCvrmWw6kZUDEd+klw6/VF5zHqhCPd+DZVYlf t02Qf9cUF3xmQ== X-Virus-Checked: Checked by ClamAV on apache.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Leon, On 7/10/14, 3:27 PM, Leon Rosenberg wrote: > answering only to the one directed at me (or so I think): ;) > On Thu, Jul 10, 2014 at 4:09 PM, Christopher Schultz < > chris@christopherschultz.net> wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> Leon, >> >>> If you have very fast connections, go for a smaller amount. If >>> you have keepalive and slow connections, remember that every >>> connection can hold 1-2 threads without doing anything at all. >> >> Hmm? >> > > If you have keepalive enabled, then every client will held an open > connection for some period of time. Correct. > Depending on browser brand and version, the browser will typically > hold 1-2 connections to the server. These days, it's more like 8. http://www.stevesouders.com/blog/2008/03/20/roundup-on-parallel-connections/ http://www.browserscope.org/?category=network http://stackoverflow.com/questions/985431/max-parallel-http-connections-in-a-browser I think most browsers will hang up the phone, though, if they aren't making any requests. > So for every logged in users that is clicking or issuing a request > regularly (maybe once a minute or so), you can end up having one > or two threads, dependending on how many connections the browsers > holds. > > Those threads would be idle most of the time, but still not > available to your threadpool. Usually they show up as Runnable > somewhere in socket.read in the thread dump. So if you have 100 > users with 150 connections and 151 threads in your threadpool you > can end up with a completely blocked server with zero cpu usage. This is one of the reasons /not/ to use a BIO-based connector, even for AJP connections: while waiting for the next keepalive request over a connection, the BIO thread will be bound to the connection, sitting there waiting and not getting anything done. The NIO connector throws the connection into a poller queue and the thread is free to do more work. So, you can either get the same amount of work done with fewer threads, or handle more work with the same number of threads. This is important when you've got many frontends and many backends so the F x B product is high, but the effective load on any server really shouldn't be anywhere near F x B. If you use BIO, your maxThreads needs to be somewhere near F x B unless you want nasty hangs, etc. If you use NIO, then maxConnections should probably be exactly F x B, but maxThreads can be significantly less than that. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTwBmtAAoJEBzwKT+lPKRYmxUQAJRoZCYvmFZWHddPlUETaOt6 2kTX08L19V16W7I5iyEhT8Zrw5mYdGXnA9FzQO0xtl7PMvfY59iIjvN+rapf347+ oFJ73cqaA4oBt7UtaMcLV5+By6CebFp2r/xb9bD0rNZ5DOBhBUJgbGbwLGTeKtAj P3LpaoodwDvWli75VLj4sgHEaAPWybuaLqRpud8W9DkhCT6DVt+RkQj3j9aDxOmu gQRB9qRGKCVExu+j5Tictmd8FHuI2Dx6gC8jsNIoMr1RUePJq835CM2OW6WPP+pa SUzddehtVAET5k4HLbFzviavMf1kBmFxSH616KRtbbZ/vtdqccWEO10GiHuCzBgH 3NlfRAsmCJWhse93zWRwX9p8HGXN2vHFl0cUlkU8yjOmGGPwSBmfE3xXtOFgFio1 yisSkCPTF0Xieyo8UcsxZkHusr/hZ6o1rCaV46zFYVMSLU7j9FDhJS+GMdljGa6y jlWnyHPGte5jbT3LsHvIxC+TBSdrX8nVXjvgV21h5YJqGimokPftHKEkiI48eebW zx5xYAJik5riAruhf+CBVCdOfQfZgIJu0S1WJ4S91HBkTLieaHHnGYuDPcoALYlC mVbyUfCnSVWpUtYVIdxEoxJeuK0jvndA2Knj/Q9D1u9fbu2ZD5heNfM0ed+3taDj ocPfNolGUZE2gMMjbkOk =v25m -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org