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 > > > > components JMeter handles > > > > > (right now there's a rigid and somewhat > > > arbitrary > > > > categorization of > > > > > components as "timers", "listeners", "config > > > > elements", "logic controllers", > > > > > and "generative controllers". "Assertions" and > > > > "Modifiers" were new > > > > > elements that have been tacked on. Using > > > Avalon, > > > > the organization of > > > > > existing and new elements would be much more > > > > flexible. > > > > > > > > All of those are good. > > > > > > > > Other examples of Avalon based projects include: > > > > Apache Cocoon > > > > Apache JAMES > > > > FOP > > > > > > > > > > > > > > Only fair to list what I see are the > > > > disadvantages: > > > > > 1. Lot's of work that will delay many new > > > features > > > > everyone wants > > > > > (cut/copy/paste, better reports/visualizers, > > > etc). > > > > > 2. Work that may interfere with what you are > > > > working on currently > > > > > > > > These disadvantages can be taken care of in a way > > > > that we are modular > > > > about what we are doing at any one time. > > > > > > > > > > > > > > And, the risks: > > > > > 1. May introduce complexity for relatively > > > little > > > > gain. Berin probably > > > > > doesn't see this as a risk, cause he is > > > > comfortable with Avalon. It looks > > > > > pretty good to me, but I see the potential that > > > > the new abstractions may > > > > > confuse things, and not produce as much benefit > > > as > > > > I think. Obviously, I've > > > > > decided this risk is small, but others may not > > > > think so. > > > > > > > > It actually reduces complexity. Currently, the > > > > JMeter code is fairly > > > > convoluted and difficult to follow. By adhering > > > to > > > > the principles of > > > > Component Oriented Programming, the system can > > > grow > > > > in a healthy manner > > > > that is flexible and easy to follow. > > > > > > > > We also gain the ability to use the test harnesses > > > > to provide sanity > > > > checks before release. > > > > > > > > > > > > > > Perhaps a branch could be made for this work. > > > I'd > > > > rather avoid that though, > > > > > if possible. > > > > > > > > > > Any thoughts? > > > > > > > > > > > > I am +1 (of course) > > > > > > > > As to the branch question, you will have to answer > > > > that based on how you > > > > feel that would manage the risk of the conversion. > > > > > > > > If you have any questions I will be happy to > > > answer > > > > them. > > > > > > > > > > > > -- > > > > > > > > "They that give up essential liberty to obtain a > > > > little temporary safety > > > > deserve neither liberty nor safety." > > > > - Benjamin Franklin > > > > > > > > > > > > -- > > > > To unsubscribe, e-mail: > > > > <mailto:[EMAIL PROTECTED]> > > > > For additional commands, e-mail: > > > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Yahoo! Sports - live college hoops coverage > http://sports.yahoo.com/ > > > > > > -- > > > To unsubscribe, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Sports - live college hoops coverage http://sports.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]> > > > > > > -- > > To unsubscribe, e-mail: > > <mailto:jmeter-dev-> [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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
