-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 André,
On 9/23/13 3:00 AM, André Warnier wrote: > Do not top-post. It makes it difficult to follow the conversation, > who answers to what etc. > >> >> >> From: Daniel Mikusa <dmik...@gopivotal.com> To: "Tomcat >> Users List" <users@tomcat.apache.org> Date: 09/20/2013 07:10 >> PM Subject: Re: MaxClients and maxThreads >> >> >> >> On Sep 20, 2013, at 9:27 AM, mohan.radhakrish...@polarisft.com >> wrote: >> >>> Is this a hard limit ? >> >> No. >> >>> So if there are 4 cores there can only be 800 concurrent >>> clients. None of our banks is calculating this like this and >>> some have Apache and JBoss on the same machine which further >>> limits the threads. >>> >>> Appreciate any help. >>> >>> Hi, I am following the instructions in >>> https://access.redhat.com/site/articles/15786 to tune >>> MaxClients in httpd.conf and maxThreads in JBoss Tomcat. " The >>> recommended value of maxThreads is 200 per CPU, so here we >>> assume the server is a single core machine. If it had been quad >>> core we could push that value to 800 or more depending on RAM >> >>> and other machine specs. The total threads is an aggregate >>> value. If Apache and JBOSS are on the same server, and that >>> server has four cores, then you would halve the maxThreads and >>> MaxClients to 400 each." >> >> Don't base your performance tuning on values you found in an >> article online. The author of this article has no idea what kind >> of hardware you are running, what your application is doing or >> what your needs are for the application. By these metrics, I >> should setup 800 threads on a quad core system, but if my >> application is only supporting 10 users that's way too many. >> Examine your needs, set the values you think will work and then >> load test to see how things perform. Adjust the settings further >> based on your load testing results. >> > mohan.radhakrish...@polarisft.com wrote: >> Yes. I understand the need for capacity planning. >> > >> It probably involves concurrency, think time analysis etc. I was >> wondering if maxThreads and MaxClients are the same value. In a >> worker mpm MaxClients is the Apache setting and maxThreads is the >> JBoss setting. >> > > In your kind of configuration, MaxClients are maxThreads are > related, but they are not the same. They may be the same if every > request received by Apache httpd is always transmitted to Tomcat. > But then what would be the point of having httpd in front ? > > >> Moreover how does a figure of 200 for a core justified. >> >> So you mean that the figure of 200 is not based on any analysis. >> > > Exactly. Not all requests are equal, and not all applications are > equal. And in processing a request, there is not only CPU time to > take into account, there is memory, I/O etc. So who, other than > you, can tell how many of *your* requests one "core" can handle in > any amount of time ? It is ridiculous to provide such a number as > if it was based on anything serious. There is one more wrinkle, here, too. Suppose you have more than one fronting server running httpd and a single back-end server running Tomcat. If you have each of your front-end servers with 200 threads, that means its possible to have 400 simultaneous requests being sent to Tomcat. If Tomcat can't handle that many simultaneous requests, you'll get timeouts, disconnects, etc. The most pathological case is when you have N httpd instances and M Tomcat instances but M-1 Tomcat instances have failed and so N*MaxClients httpd requests are being sent to a single Tomcat instance. You just need to make sure you plan for that kind of situation and understand what will happen in those cases. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSQDcaAAoJEBzwKT+lPKRYOecQAJWY4H3BACTlBc9rApSZFd79 9xOz/2m7WGc45xRXsTED3katdtTu13ZkDxHB3iHK9jUzZ5LKlOE2npw9V7WaqyQF kQphbBcSIbG5fr5rWN73Hbt5laYOcSXdgSd1k7WyCjzThFre7zDeDy6A9GSXnzYI MH+C9Ddxy9wvujYdXnOACkXqck1vxJk19QlCGQrsWHYTdmmEEvahNYHjCSliaPVE Jz+Z/ZemP74fvi3RmFa9Mm350zyamnOvOEQeDTmwd87VxbvrRaRlAmuhnjSf16SA 4p94xF0Z1ppNbVnFoPL2qKQNmVDDXtbp7oTFpFtXa9Gc51KzGltP55y1zZqvTK+7 XmakjOpwRL6n/4xRBkuWKpCqXfzv+XTq8DPeHWfPeX3gWnbbZrbc4Dv+LlY/usyY to0uwQHsJ0aCzvLXfzMdXImGhCos09OpKE0f3RiAqRGJw+TdHZIFQJYiL92Lu37C 1Q5Nx1H7T4US6v8D9Ayl/6m7htj1wxOtqt00LxBXuNVJP1Y0sG3XzSZ1zW93eiSn ThfLKxKhmDhWWv4DYXHfZsWi+iueLM/zwthV8hiGtX9dcCvRndUhM2GViIHybP2O hBcqFQA7KZQu6f1JI2viIycw5kluQJNU/Iaugb/lNBMIuNKCEPv73K56aLnbycZF Ctvmo+SkUoYwMt2p29yi =c87Z -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
