Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 12969 invoked by uid 500); 4 Dec 2001 10:25:17 -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 12958 invoked from network); 4 Dec 2001 10:25:16 -0000 Sender: skc@mailrelay2.ornis.com Message-ID: <3C0CA5D5.B484C340@ivision.fr> Date: Tue, 04 Dec 2001 11:30:45 +0100 From: Sebastien Koechlin Organization: IVision X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: fr, en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: Cocoon 2.0 Scalability Disappointment References: <3C07C3FB.F14AEDF@apache.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Stefano Mazzocchi wrote: > 2) they admit the Cocoon 2.0 cache system is likely to provide huge > benefits for them, but they are not sure they are using it properly. It was to monitor who does cache is working that I wrote something about "Improving StatusGenerator". I think that for each cached stream/event, we should record a creation timestamp and increment a counter each time the cached object is served. On the status page, displaying thoses values allow us to see if cache is used where it is expected to. - If nothing is listed : cache is not active. - If counter is 0 or 1 : cache is re-generated each time. -- S�bastien Koechlin - IVision - skoechlin@ivision.fr --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org