You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Matt Hogstrom <ma...@hogstrom.org> on 2007/10/01 21:56:00 UTC
DayTrader - porting MarketSummaryInterval changes from 2.0 to 1.2 and preparing to release
I'm going to port the market summary interval changes back from 2.0
to 1.2 so we can get comparable numbers between the versions. With
that I'd like to sugggest we wrap up 1.2 and 2.0 and release these.
Are there any outstanding changes folks want before we let these
releases out?
Re: DayTrader - porting MarketSummaryInterval changes from 2.0 to 1.2 and preparing to release
Posted by Matt Hogstrom <ma...@hogstrom.org>.
heh .. didn't mean to derail discussion. I think what would make
sense would be to move the web services from runtime mode to a set of
primitives. Does it make sense to also rework the message for what
DayTrader is all about?
On Oct 3, 2007, at 1:34 PM, Christopher Blythe wrote:
> ahh... come on matt... this is good discussion... we finally have
> people thinking (and talking) about where we should or shouldn't
> take DayTrader in the future. there hasn't been enough of that!
>
> i think short term, the disclaimers serve the purpose. however,
> long term... daytrader will lose it's relevance if it isn't updated
> to reflect how people are using the technology.
>
> On 10/3/07, Matt Hogstrom <ma...@hogstrom.org> wrote:
> So to cl;arify I think DayTrader may be mis-characterized as only a
> benchmark. I think it is used for a variety of functions of which
> only one aspect is performance. the other aspects are testing
> infrastructure, sample application (which includes deployments
> plans for various pieces of functionality, etc.).
>
> With that in mind perhaps we should change it from performance
> benchmark to something else. I'm concerned about pulling this at
> the very end. I agree that we don't want to put out a sample that
> can be used inappropriately but in the end we don't really tell
> anyone what they can do with the software. I'm concerned about
> making changes to DayTrader because of commercial positioning. For
> this reason I'd rather add the comment about relevance of the
> runtime mode. I think simply adding the comment is adequate.
>
> If we're going for best practices I don't think anyone would say
> the app as it is written today is a best practice but more of a
> swiss army knife of tools.
>
> It sounds like there are varying viewpoints so perhaps we let the
> discussion percolate and put it to a vote.
>
> On Oct 3, 2007, at 12:25 PM, Christopher Blythe wrote:
>
>> ah.... now you're pointing out the distinctions between primitives
>> and a real application "workload". currently, the web services
>> within daytrader are presented in the context of a "workload" not
>> a primitive.
>
>
>
>
> --
> "I say never be complete, I say stop being perfect, I say let...
> lets evolve, let the chips fall where they may." - Tyler Durden
Re: DayTrader - porting MarketSummaryInterval changes from 2.0 to 1.2 and preparing to release
Posted by Christopher Blythe <cj...@gmail.com>.
ahh... come on matt... this is good discussion... we finally have people
thinking (and talking) about where we should or shouldn't take DayTrader in
the future. there hasn't been enough of that!
i think short term, the disclaimers serve the purpose. however, long term...
daytrader will lose it's relevance if it isn't updated to reflect how people
are using the technology.
On 10/3/07, Matt Hogstrom <ma...@hogstrom.org> wrote:
>
> So to cl;arify I think DayTrader may be mis-characterized as only a
> benchmark. I think it is used for a variety of functions of which only one
> aspect is performance. the other aspects are testing infrastructure, sample
> application (which includes deployments plans for various pieces of
> functionality, etc.).
> With that in mind perhaps we should change it from performance benchmark
> to something else. I'm concerned about pulling this at the very end. I
> agree that we don't want to put out a sample that can be used
> inappropriately but in the end we don't really tell anyone what they can do
> with the software. I'm concerned about making changes to DayTrader because
> of commercial positioning. For this reason I'd rather add the comment about
> relevance of the runtime mode. I think simply adding the comment is
> adequate.
>
> If we're going for best practices I don't think anyone would say the app
> as it is written today is a best practice but more of a swiss army knife of
> tools.
>
> It sounds like there are varying viewpoints so perhaps we let the
> discussion percolate and put it to a vote.
>
> On Oct 3, 2007, at 12:25 PM, Christopher Blythe wrote:
>
> ah.... now you're pointing out the distinctions between primitives and a
> real application "workload". currently, the web services within daytrader
> are presented in the context of a "workload" not a primitive.
>
>
>
--
"I say never be complete, I say stop being perfect, I say let... lets
evolve, let the chips fall where they may." - Tyler Durden
Re: DayTrader - porting MarketSummaryInterval changes from 2.0 to 1.2 and preparing to release
Posted by Matt Hogstrom <ma...@hogstrom.org>.
So to cl;arify I think DayTrader may be mis-characterized as only a
benchmark. I think it is used for a variety of functions of which
only one aspect is performance. the other aspects are testing
infrastructure, sample application (which includes deployments plans
for various pieces of functionality, etc.).
With that in mind perhaps we should change it from performance
benchmark to something else. I'm concerned about pulling this at the
very end. I agree that we don't want to put out a sample that can be
used inappropriately but in the end we don't really tell anyone what
they can do with the software. I'm concerned about making changes to
DayTrader because of commercial positioning. For this reason I'd
rather add the comment about relevance of the runtime mode. I think
simply adding the comment is adequate.
If we're going for best practices I don't think anyone would say the
app as it is written today is a best practice but more of a swiss
army knife of tools.
It sounds like there are varying viewpoints so perhaps we let the
discussion percolate and put it to a vote.
On Oct 3, 2007, at 12:25 PM, Christopher Blythe wrote:
> ah.... now you're pointing out the distinctions between primitives
> and a real application "workload". currently, the web services
> within daytrader are presented in the context of a "workload" not a
> primitive.
Re: DayTrader - porting MarketSummaryInterval changes from 2.0 to 1.2 and preparing to release
Posted by Christopher Blythe <cj...@gmail.com>.
ah.... now you're pointing out the distinctions between primitives and a
real application "workload". currently, the web services within daytrader
are presented in the context of a "workload" not a primitive.
if you want to measure the web services overhead and the impact of payloads
with varying size and complexity, primitives are the right way to go. i've
seen several web services benchmarks geared towards this and am not sure if
daytrader is the right place to repeat them.
On 10/3/07, David Jencks <da...@yahoo.com> wrote:
>
>
> 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* <jgenender@apache.org
> >> <ma...@apache.org>> 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* <matt@hogstrom.org
> >> <ma...@hogstrom.org>
> >>> <mailto:matt@hogstrom.org <ma...@hogstrom.org>>> 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
>
>
--
"I say never be complete, I say stop being perfect, I say let... lets
evolve, let the chips fall where they may." - Tyler Durden
Re: DayTrader - porting MarketSummaryInterval changes from 2.0 to 1.2 and preparing to release
Posted by David Jencks <da...@yahoo.com>.
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* <jgenender@apache.org
>> <ma...@apache.org>> 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* <matt@hogstrom.org
>> <ma...@hogstrom.org>
>>> <mailto:matt@hogstrom.org <ma...@hogstrom.org>>> 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
Re: DayTrader - porting MarketSummaryInterval changes from 2.0 to
1.2 and preparing to release
Posted by Jeff Genender <jg...@apache.org>.
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.
Jeff
> On 10/3/07, *Jeff Genender* <jgenender@apache.org
> <ma...@apache.org>> 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* <matt@hogstrom.org
> <ma...@hogstrom.org>
> > <mailto:matt@hogstrom.org <ma...@hogstrom.org>>> 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
Re: DayTrader - porting MarketSummaryInterval changes from 2.0 to 1.2 and preparing to release
Posted by Christopher Blythe <cj...@gmail.com>.
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.
On 10/3/07, Jeff Genender <jg...@apache.org> 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* <matt@hogstrom.org
> > <ma...@hogstrom.org>> 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
Re: DayTrader - porting MarketSummaryInterval changes from 2.0 to
1.2 and preparing to release
Posted by Jeff Genender <jg...@apache.org>.
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* <matt@hogstrom.org
> <ma...@hogstrom.org>> 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
Re: DayTrader - porting MarketSummaryInterval changes from 2.0 to 1.2 and preparing to release
Posted by Christopher Blythe <cj...@gmail.com>.
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.
On 10/2/07, Matt Hogstrom <ma...@hogstrom.org> 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
Re: DayTrader - porting MarketSummaryInterval changes from 2.0 to 1.2 and preparing to release
Posted by Matt Hogstrom <ma...@hogstrom.org>.
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.
Re: DayTrader - porting MarketSummaryInterval changes from 2.0 to 1.2 and preparing to release
Posted by Christopher Blythe <cj...@gmail.com>.
Matt...
Here are a few minor things that come to mind.
- Ensure license files, etc. are up to snuff
- Review readme files to make sure instructions are correct. For the J2EE
client apps, there should be
some mention of setting the "endorsed" directory
- Make sure config changes are propagated to the web.xml
There is one major thing I wanted to mention. For those that haven't seen
it, Microsoft published a StockTrader benchmark based on Trade 6.1 (which
served as the basis for DayTrader). Here is a link for members of the list
to review.
http://msdn2.microsoft.com/en-us/netframework/bb499684.aspx
They have used this benchmark to market .NET as a player in the SOA space by
publishing web services numbers using the web services mode available within
Trade/DayTrader (among other modes) that pit .NET versus WebSphere. For
those interested, please review the MS documentation and then read the
response from Andrew Spyker (on the WebSphere community blog) at the
following link.
http://webspherecommunity.blogspot.com/2007/09/perspective-in-benchmarks-my-thoughts.html
As Andrew Spyker suggests in the blog entry, the web services in
Trade/DayTrader are extremely fine-grained (avg. about 500 bytes/req) which
does not comply with just about every web services best practices document
I've ever read. Based on this, I would like to propose that the the web
services in their current form be removed from DayTrader.
I had mentioned this previously and met some opposition as several people
cited the web services within DayTrader as an functional sample of web
services. I completely understand the need to have a web services sample.
However, if you portray DayTrader as a performance benchmark (as I think we
should), we should make every effort to ensure that all modes within the
benchmark are designed with all best practices in mind. If Microsoft can do
this kind of "Bench-marketing" with Trade 6.1 and WebSphere, we should be
proactive and prevent them from doing the same with DayTrader and any other
J2EE vendor.
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.
Ok.... that's all for my rant.... any thoughts?
Chris
On 10/1/07, Matt Hogstrom <ma...@hogstrom.org> wrote:
>
> I'm going to port the market summary interval changes back from 2.0
> to 1.2 so we can get comparable numbers between the versions. With
> that I'd like to sugggest we wrap up 1.2 and 2.0 and release these.
>
> Are there any outstanding changes folks want before we let these
> releases out?
>
--
"I say never be complete, I say stop being perfect, I say let... lets
evolve, let the chips fall where they may." - Tyler Durden