Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 62989 invoked by uid 500); 6 Feb 2003 03:53:26 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 62967 invoked from network); 6 Feb 2003 03:53:25 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Niclas Hedhman To: cocoon-dev@xml.apache.org Subject: Re: [TIPS] Basic configurations of Apache 2.0 for Cocoon 2 Date: Thu, 6 Feb 2003 11:47:09 +0800 X-Mailer: KMail [version 1.4] References: In-Reply-To: X-Accept-Language: en en_us MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200302061147.09090.niclas@hedhman.org> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Thursday 06 February 2003 02:26, Pier Fumagalli wrote: > Oh, absolutely, I don't like that either... But in my specific case (VN= U, > with somewhat 8000/9000 hits per minute (we peak up sometimes at 400 hi= ts > per second), we need to use tricks (yes, tricks/hacks) to make that hap= pen, > because passing through (even on localhost) binary data at that rate is > sometimes overkilling... Shouldn't you in this case have front-end load balancing routers (various= =20 topologies available) to lower the load on each server? Sounds like you are spending thousands of engineering dollars in optimiza= tion=20 solutions, when the same dollars can buy you a quick and reliable solutio= n=20 off-the-shelf.... And you can spend that engineering time on something mo= re=20 useful. Niclas --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org