Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@www.apache.org Received: (qmail 52220 invoked from network); 20 Nov 2004 13:22:19 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 20 Nov 2004 13:22:18 -0000 Received: (qmail 27629 invoked by uid 500); 20 Nov 2004 13:22:10 -0000 Delivered-To: apmail-jakarta-tomcat-dev-archive@jakarta.apache.org Received: (qmail 27540 invoked by uid 500); 20 Nov 2004 13:22:10 -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 27522 invoked by uid 99); 20 Nov 2004 13:22:09 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from [204.74.20.252] (HELO sid.armstrong.com) (204.74.20.252) by apache.org (qpsmtpd/0.28) with ESMTP; Sat, 20 Nov 2004 05:22:05 -0800 Received: from [192.168.1.101] (pcp01470022pcs.lncstr01.pa.comcast.net [68.82.237.147]) by sid.armstrong.com (8.12.8p1/8.12.8) with ESMTP id iAKDM0Tj003349 for ; Sat, 20 Nov 2004 08:22:01 -0500 Message-ID: <419F44F1.4090906@joedog.org> Date: Sat, 20 Nov 2004 08:21:53 -0500 From: Tim Funk Organization: Human being User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en, es-mx, de, sv MIME-Version: 1.0 To: Tomcat Developers List Subject: Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves ByteBufferAccessLogValve.java mbeans-descriptors.xml References: <20041119164627.57074.qmail@minotaur.apache.org> <419E2AAB.9080003@apache.org> <419E3511.10809@apache.org> <419E4303.8040503@apache.org> <419E441B.1040303@apache.org> <419F1039.8080201@apache.org> In-Reply-To: <419F1039.8080201@apache.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N I never thought about it this way, but can the comparisons be made by using and not using Keep-Alive? I would guess that if Keep-alive is used - there would be a performance gain since the same thread needs to wait for the valve to write its log entry, before the next item in keep alive request is made. If keep alive is turned off, there would be no performance boost - unless all the threads were in use. I'm just playing devil's advocate. I ran some tests with AccessLogValve turned on vs turned off on some HP-UX boxes and saw no performance difference. So either my test was bad, or the HP os/disks we use do an awesome job of caching in the disk controller to provide superb I/O performance. If I weren't swamped with my day job, I'd love to refactor access log valve into 2 parts: - The pattern creator. This creates the line item which needs logged. For example: Standard or Extended. This piece would decide when or when not to log. - A writer. A set of classes (some possibly abstract to inherit from) which allow logging in a variety of manners such as: FileLogger, BufferedLogger, PipedLogger, FileSizeLogger(rotate on size), FileDateLogger(rotate on Date), CombinedLogger (a stub which talks to a some controller which combines all the logs in a cluster into one file) [But since I have no code to contribute at this time, I'll just stay quiet.] -Tim Remy Maucherat wrote: > Jean-Francois Arcand wrote: > >> Without access log valve, we are 20% faster. With the ByteBuffer one, >> 13%. > > > There are 3 access log valves ;) Maybe you should give a chart. > > I'll do my byte based improvements (to be able to save on char to byte) > in your implementation. > > The buffer isn't big enough. 16k will hold 500 requests maximum. If you > were afraid of doing one I/O operations, it's bad, as you'll end up > doing a lot of I/O synchronously. Can we allow the buffers to grow ? At > least they would need to be a lot bigger otherwise (we could "reinvest" > the memory saved from not having a background thread :) ). > Another trick if you want to tweak the interval inside the valve, you > can use an integer that you increment and do a modulo (i % n). I do that > for the manager checks (one check every 6 invocations of > backgroundProcess). > --------------------------------------------------------------------- To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org