Hi Gato, On 1/30/07, Gaston Dombiak <[EMAIL PROTECTED]> wrote:
Hey guys, That is exactly what I needed for out load testing analysis. We needed to be able to get the total numbers instead of per connection number.
Glad that you gave us a positive response. The nice thing of the current StatCollector implementation is that if you
are not interested in stats then there is no overhead since there is no polling. However, having a poll mechanism makes the overall solution more complex compared to the option of just changing the sessions to add up their stats to the service stats.
True. Our design policy on JMX integration won't change much for sure. "It'll improve performance a for people who just want to see the service
throughtput.". I'm not sure about performance but for sure it will help to get a more accurate stat of a snapshot in a given point in time. Anyway, I think that the margin of error is acceptable when using the polling method. We were testing with 30K sessions and I agree that iterating on them is not as iterating on 10 elements. :) Having said that, I like the idea of just adding up stats in the service object based on session notifications. However, we need to be very careful to monitor possible overhead of this option. My guess is that the overhead (that will exist) will be practically minimal thus acceptable.
I agree with you here too. We can live with current calculation algorithm, but we know there's a simpler way. Let me fix the performance problem in 1.x branch as a temporary fix, and do the right thing (i.e. simplifying calculation) in trunk. Your JIRA issues could be resolved separately from this standpoint. WDYT? BTW, I tried to find Julien's post about his feedback regarding the
suggested fix/improvement but it seems that I lost it. :( However, I do remember that he mentioned something about that rates are no longer supported but numbers. The reason for such modification were 2: 1) Rates can be calculated based on the total number and the frequency of getting those numbers and 2) in our case seeing the total number (instead of rate) was more meaningful. :)
Right. In 2.0, we are going to provide both. HTH, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
