If we are moving to Avalon, could we not include components that take advantage of the JDK1.4 if it exists, but are not present otherwise?
I think that the non-blocking IO introduced in JDK 1.4 could have significant positive impacts on JMeter - both in the product's functionality and performance. BTW - is the 'officially supported' JDK for JMeter still 1.2? -----Original Message----- From: kevin hammond [mailto:[EMAIL PROTECTED]] Sent: Sunday, March 24, 2002 12:00 PM To: JMeter Developers List; [EMAIL PROTECTED] Subject: RE: using Avalon Hi, I would think twice about including JDK1.4 code in JMeter. That would severely limit who can run JMeter. We would be forcing most people/companies to install JDK1.4 just to use JMeter. -- Kevin --- "Stover, Michael" <[EMAIL PROTECTED]> wrote: > It would be a very easy thing to add the latency > time to the SampleResults. > I will probably get to it sometime during 1.8 > development. I have also been > considering taking advantage of jdk1.4's > non-blocking IO to use only a few > threads for all the requests. It seems like doing > so would increase the > complexity of the Sampler interface for people > writing new protocol testers. > But, it might worth experimenting with. > > Another though I've had is to have JMeter modify the > number of threads to > find the maximum throughput performance of a server > - how many threads > results in the server's highest throughput. I think > that would be useful to > know, and I see no reason why JMeter couldn't find > this point automatically. > > -Mike > > > -----Original Message----- > > From: Berin Loritsch [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, March 21, 2002 9:11 AM > > To: 'JMeter Developers List' > > Subject: RE: using Avalon > > > > > > Avalon is already used in Cocoon, which is meant > for the web server. > > I have used it in a number of projects. It is > very quick. Of course, > > a lot of perceived quickness depends on how you > implement things. > > > > For instance, if the goal is to saturate a server > with connections in > > order to test how much load it can support before > it dies, the > > traditional > > Thread Per Connection approach will cause issues > in JMeter itself. > > Using > > non-blocking IO, we can have a handful of threads > manage all the > > connections, > > and create several thousand connections with only > a few threads in > > comparison. > > > > If the goal is to measure latencies (time from > request to > > first byte of > > response) > > as well as overall time, then we almost need the > thread per connection > > approach so we don't measure time for the socket > selector to > > notify our > > code. > > > > With either approach, you can measure trends in > load. I.e. find the > > slope of the > > S-curve to find where saturation occurs. BTW, all > scalability graphs > > exhibit an > > S-Curve. With relatively few connections, > response times don't change > > that much. > > As we add more connections, the response times > will continue to grow > > until we > > hit the saturation point. Once we hit the > saturation point, response > > times won't > > grow because the connections are lost. The > interesting part of the > > scalability > > graph is finding the slope of the critical > portion. > > > > I had posted a lengthy message in the past where I > wanted to > > have JMeter > > to be > > able to take different types of samples. For > instance, useful data > > would be > > the number of images per page or the size of the > page/image. Other > > useful info > > would be latency (time to first response) as well > as the > > current time to > > complete > > response. > > > > > -----Original Message----- > > > From: Jamie Davidson > [mailto:[EMAIL PROTECTED]] > > > Sent: Thursday, March 21, 2002 8:05 AM > > > To: 'JMeter Developers List' > > > Subject: RE: using Avalon > > > > > > > > > Any ideas on how this change would affect the > overall > > > performance of JMeter? > > > And - BTW - who gets to vote? - if it means > anything, +1. > > > > > > -----Original Message----- > > > From: Boutcher, James K. > [mailto:[EMAIL PROTECTED]] > > > Sent: Tuesday, March 19, 2002 11:26 AM > > > To: JMeter Developers List > > > Subject: RE: using Avalon > > > > > > > > > Sorry for taking so long - had to find the time > to check it out.. > > > > > > +1 > > > > > > -----Original Message----- > > > From: kevin hammond > [mailto:[EMAIL PROTECTED]] > > > Sent: Tuesday, March 19, 2002 6:48 AM > > > To: JMeter Developers List > > > Subject: Re: using Avalon > > > > > > > > > I vote +1 for moving JMeter to use the Avalon architecture. > > > > > > Thanks, > > > Kevin Hammond > > > > > > --- kevin hammond <[EMAIL PROTECTED]> > wrote: > > > > Hi, > > > > > > > > I will send in my vote this weekend after > reading > > > > more > > > > about the Avalon architecture. > > > > > > > > Mike, do you have any guesstimates on how long > the > > > > conversion would take? Weeks? Months? > > > > > > > > We really need to create at least one branch. > > > > Always > > > > working off the mainline is one of the reasons > we > > > > cannot get a new release out. People keep > checking > > > > in > > > > brand new code/functionality. > > > > > > > > Thanks, > > > > Kevin > > > > > > > > --- Berin Loritsch <[EMAIL PROTECTED]> > wrote: > > > > > Stover, Michael wrote: > > > > > > Hi all, > > > > > > Berin has convinced me that using the > > > > > Avalon-Excalibur framework in > > > > > > JMeter would be helpful. I'd like to know > if > > > > > everyone is agreeable to > > > > > > letting me rework JMeter's structure to do > this. > > > > > > > > > > > > to be specific, it will require changing > the > > > > > interfaces (such as > > > > > > JMeterComponentModel and ModelSupported, > > > > Saveable, > > > > > etc). The way new > > > > > > components would be written would change > (the > > > > idea > > > > > is to make is easier and > > > > > > more consistent). > > > > > > > > > > > > I think the benefits of this would be: > > > > > > 1. Simpler and more consistent process to > create > > > > > new components > > > > > > 2. Remove dependence on Swing in non-gui > classes > > > > > > 3. Better design resulting in easier to > manage > > > > and > > > > > less buggy code > > > > > > 4. Possibly more flexibility in the types > of > === message truncated === __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy AwardsR http://movies.yahoo.com/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
