Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 53518 invoked from network); 3 Oct 2007 15:53:11 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 3 Oct 2007 15:53:11 -0000 Received: (qmail 5504 invoked by uid 500); 3 Oct 2007 15:51:47 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 5464 invoked by uid 500); 3 Oct 2007 15:51:47 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 5452 invoked by uid 99); 3 Oct 2007 15:51:47 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Oct 2007 08:51:47 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [69.147.95.88] (HELO smtp125.plus.mail.sp1.yahoo.com) (69.147.95.88) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 03 Oct 2007 15:51:47 +0000 Received: (qmail 99328 invoked from network); 3 Oct 2007 15:42:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer; b=bMWTioGpdnn/i5kiDwBMVThkYGffBYM1SqIuRRFHHjiVWuXCv0aSBUqyVSyHOdCiFcvTjdBpSw2oE2YwDLS4SAFRMssqi+3rSHVRyCJEDEQkUwlH5+aaoh9xcJlitpIzgZiB2AgLnwIx/GGOk31Zfha2/UrI2RuoFXzcYksCN0c= ; Received: from unknown (HELO ?192.168.1.101?) (david_jencks@67.102.173.8 with plain) by smtp125.plus.mail.sp1.yahoo.com with SMTP; 3 Oct 2007 15:42:04 -0000 X-YMail-OSG: WbO9tPMVM1k5.dhaU4xjKCbFY7z.Bq2ixJFLK._JxUFNabfTBI1l05H.vNyFFmzNc9WQmkJWKg-- Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <4703A8E3.607@apache.org> References: <605ED3FA-6525-4C53-8E22-2AC15135517D@hogstrom.org> <421012bd0710012023w7065bceepc2dd60126247882c@mail.gmail.com> <2255C600-78C4-49FB-94EB-7C1BB39223C5@hogstrom.org> <421012bd0710030631l254dcea2k75cd58e9d036cad4@mail.gmail.com> <47039AC8.6050009@apache.org> <421012bd0710030732t4f574177gc2b6cbb66807ae8f@mail.gmail.com> <4703A8E3.607@apache.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <390A2BCB-CBC0-4D2B-A7D5-0E32D7018F23@yahoo.com> Content-Transfer-Encoding: 7bit From: David Jencks Subject: Re: DayTrader - porting MarketSummaryInterval changes from 2.0 to 1.2 and preparing to release Date: Wed, 3 Oct 2007 08:42:05 -0700 To: dev@geronimo.apache.org X-Mailer: Apple Mail (2.752.3) X-Virus-Checked: Checked by ClamAV on apache.org On Oct 3, 2007, at 7:36 AM, Jeff Genender wrote: > > > Christopher Blythe wrote: >> Jeff... I agree with you on both counts. Perhaps I should present >> this >> from another vantage point. If you were an application developer, >> would >> you use web services in the manner they are currently used in >> DayTrader? >> Or would you try to adhere to most documented best practices and >> steer >> clear of very chatty (fine-grained) web services calls. If we >> would like >> to keep web services in DayTrader, I think they should be re- >> vamped to >> re-align with a scenario/pattern that is better suited for web >> services >> and reflect how they are predominantly used in the industry. >> > > Yep...you are going exactly where I was ;-) > > If DT is not using WS the way it should be, then absolutely it > should be > redone and developed in a best practice manner. well I'm confused now.... pingServlet is not a realistic imitation of any real business operation, but it is useful to measure the overhead of the web container. Aren't our current dt web services pretty much similar to pingServlet and measure the overhead of the ws stack with no data processing taking place? I think it would be useful to also measure what happens if you send a realistically sized xml doc back and forth while doing nothing with it, but the overhead with a minimal xml doc seems useful to me also. Similarly, we could (and might.... I dont know) measure the overhead of sending a large form and returning a complicated static page while doing no application processing for the web container. does this make any sense? thanks david jencks > > Jeff > > > >> On 10/3/07, *Jeff Genender* > > wrote: >> >> >> >> Christopher Blythe wrote: >>> Actually, I'm suggesting we pull the web services out of >>> DayTrader all >>> together and write another web services sample app. If DayTrader is >>> truly meant to be a "performance benchmark", why would you leave >>> something in there that is in clear violation of performance best >>> practices. Doesn't exactly send the right message if you ask me. >>> >> >> That really depends what you are trying measure. Are you >> trying to >> measure raw-throughput (ping servlet, etc), or are you trying >> to measure >> how a JavaEE5 application using standard components is going >> to perform >> (more realistic)? >> >> IMHO, I think Daytrader is a neat application that lets you >> kind of >> configure what you want to test and how you want to test it. Its >> interesting because I haven't seen anything else out there >> that does >> this...it really is a good way to measure most components of a >> standardized stack. >> >> Jeff >> >>> On 10/2/07, *Matt Hogstrom* > >>> >> wrote: >>> >>> >>> On Oct 1, 2007, at 11:23 PM, Christopher Blythe wrote: >>> >>>> Matt... >>>> >>>> >>>> In summary, I guess I really just wanted to say that I feel >> the web >>>> services modes in DayTrader should be removed at least until >> we can >>>> come up with something better. If the only reason to keep these >>>> around is to provide a "sample" and not a performance benchmark, >>>> lets come up with some other sample that demonstrates web >> services. >>>> >>> >>> You make a good point about the WebServices. I'd suggest >>> that we >>> document the current limitations of comparing these >>> WebServices in >>> performance benchmarks. That should help to set everyone's >>> expectations about the relevant usefulness of the data. >>> >>> For WebServices it sounds like your suggesting that we >> deprecate web >>> services for performance work rather than for functional >>> purposes >>> like was done for the MDB primitives. I'd be for adding the >> warning >>> in a readme. >>> >>> >>> >>> >>> -- >>> "I say never be complete, I say stop being perfect, I say let... >>> lets >>> evolve, let the chips fall where they may." - Tyler Durden >> >> >> >> >> -- >> "I say never be complete, I say stop being perfect, I say let... lets >> evolve, let the chips fall where they may." - Tyler Durden