Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@www.apache.org Received: (qmail 76537 invoked from network); 17 Mar 2004 17:43:06 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 17 Mar 2004 17:43:06 -0000 Received: (qmail 13862 invoked by uid 500); 17 Mar 2004 17:42:53 -0000 Delivered-To: apmail-jakarta-tomcat-dev-archive@jakarta.apache.org Received: (qmail 13739 invoked by uid 500); 17 Mar 2004 17:42:52 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 13720 invoked from network); 17 Mar 2004 17:42:51 -0000 Received: from unknown (HELO galen.earthdome.org) (206.152.117.245) by daedalus.apache.org with SMTP; 17 Mar 2004 17:42:51 -0000 Received: from gkar.earthdome.org (110.mnetw.more.net [207.160.138.110]) by galen.earthdome.org (Postfix) with ESMTP id BD5AA13108 for ; Wed, 17 Mar 2004 11:42:53 -0600 (CST) Received: by gkar.earthdome.org (Postfix, from userid 501) id 2124914794A; Wed, 17 Mar 2004 11:42:35 -0600 (CST) Date: Wed, 17 Mar 2004 11:42:35 -0600 From: Glenn Nielsen To: Tomcat Developers List Subject: Re: jk2 new shmem using APR Message-ID: <20040317174235.GU8313@gkar.earthdome.org> References: <20040317044942.GN8313@gkar.earthdome.org> <04Mar17.082604pst."964064"@kaibab.parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <04Mar17.082604pst."964064"@kaibab.parc.xerox.com> User-Agent: Mutt/1.4.1i X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N One thing I forgot to mention is that when using the worker MPM and mod_jk with Tomcat it helps reduce Tomcat overhead by reducing the number of Connectors Tomcat requires due to mod_jk being able to use a cached pool of connectors to Tomcat per process. This really helped Tomcat scale better. From requiring 500 Connectors to Tomcat with Apache 1.3 we now rarely need more than 50 connectors to Tomcat with Apache 2. Regards, Glenn On Wed, Mar 17, 2004 at 08:25:59AM -0800, Paul Rasmussen wrote: > Thanks a lot for this synopsis Glenn. Obviously I am also considering whether > I should recommmend moving to Apache2 to our team. > > - paul r. > > In message <20040317044942.GN8313@gkar.earthdome.org>you write: > >On Tue, Mar 16, 2004 at 02:48:26PM -0000, Greg.Cope@pfizer.com wrote: > >> > Greg, > >> As an aside our team will be looking at apache2 and tomcat5 sooner rather > >> than later as it would appear that more development effort is taking place > >> on these platforms. However balancing lots of apps and infrastructure > >> upgrades and testing with day to day support means this will not happen > >> soon. > > > >I went through the process of upgrading our servers to Apache2 over > >the last 9 months. These are Sun servers running Solaris and using > >the Apache 2 worker MPM. There are alot of advantages to upgrading. > >My testing found Apache 2 to require a great deal fewer system resources > >(CPU,memory) when using the worker MPM and be much more scaleable. > >I also like the way filters work. You can now have Tomcat generate HTML > >with SSI which mod_include can then parse. This can help scaling for > >Tomcat. We use it with Tomcat4 and mod_jk 1.2.5, both are working very > >reliably for us. > > > >I did run into a number of problems at first. Most of them were > >Solaris specific. And some bugs which caused problems. I ended > >up learning a whole lot more about apache internals than I really > >wanted to, and even submitted a number of patches which got rolled > >into later releases. > > > >All in all it is working pretty well for us but we still get some > >core dumps once in a while, nothing that causes apache to completely > >fail though. We do have one nasty bug we hope the 2.0.49 release will > >fix. That is a runaway apache process which consumes all memory on > >the server. That was pretty nasty until we used ulimit on solaris > >to limit the size of the data and virtual memory segments for apache > >processes. Now the infrequent times this bug is triggered the apache > >process core dumps when it hits these memory limits rather than > >causing general failures on the server due to exhausing all physical > >and virtual memory. > > > >The biggest effort had to be put into making sure all the third > >party apache modules we use were thread safe. This included patches > >to mod_jk 1.2 to fix a few thread safe problems. The mod_jk 1.2.5 > >includes all these patches. > > > >All in all it was worth the effort, 9 months later it should be > >easier for someone with a similar environment to mine to upgrade > >to apache 2. > > > >Regards, > > > >Glenn > > > >---------------------------------------------------------------------- > >Glenn Nielsen glenn@more.net | /* Spelin donut madder | > >MOREnet System Programming | * if iz ina coment. | > >Missouri Research and Education Network | */ | > >---------------------------------------------------------------------- > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org > >For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org ---------------------------------------------------------------------- Glenn Nielsen glenn@more.net | /* Spelin donut madder | MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | ---------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org