Re: [Grinder-use] Instrumentation Question
Distributed load testing framework - Java, Jython, or Clojure scripts.
Brought to you by:
philipa
Menu
▾
▴
Re: [Grinder-use] Instrumentation Question
|
From: Ouray V. <ou...@vi...> - 2012-05-30 16:46:01
|
After reading the slf4j site, I realize that the lack of grinder logs is caused by the JVM binding to my version of the jar first. On Wed, May 30, 2012 at 12:37 PM, Ouray Viney <ou...@vi...> wrote: > Hi Philip: > > The more I look at this, the more I realize I should probably resolve the > logback issues with Grinder 3.9.1 and my Java performance test wrapper > (client stubs). > > The issue currently presented when running with 3.9.1 is that Grinder > makes use of logback- classic.jar as does my Java performance test wrapper. > The grinder logs are created but are empty, which makes me think the > logback implementation in my Java performance wrapper is swallowing Grinder > logs. > > SLF4J: Class path contains multiple SLF4J bindings. > SLF4J: Found binding in > [jar:file:/C:/workspace/EST2_Desktop/lib/logback-classic.jar!/org/slf4j/impl/StaticLoggerBinder.class] > SLF4J: Found binding in > [jar:file:/D:/Headwall_Software/Projects/Innovapost/development/grinder-3.9.1/lib/logback-classic-1.0.0.jar!/org/slf4j/impl/StaticLoggerBinder.class] > SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an > explanation. > > I haven't tried fixing it yet (I presume I'll have to consolidate the xml > files that define what logs are what etc and re-bundle the jar), but will. > Please feel free to suggest a fix if you have already dealt with this > before. > > Kind Rgds, > > Ouray > > On Wed, May 30, 2012 at 12:23 PM, Philip Aston <ph...@ma...> wrote: > >> >> OK, so you're using Jython 2.5.2, so you must be using DCR. >> >> The difference between the two must be that DCR is instrumenting more of >> the target object. Its also treating Test 1 as a composite test, which is a >> little strange. I think you are running into bugs in 3.4, in particular >> 2992248. Search http://grinder.sourceforge.net/development/changes.htmlfor "DCR" to see the number of fixes in 3.5-3.7. >> >> Does the logback clash prevent you from trying 3.9.1? If so, what errors >> do you get? >> >> - Phil >> >> >> >> On 30/05/12 16:03, Ouray Viney wrote: >> >> Hi Philip: >> >> Hrm... in Grinder 3.4, with Jython 2.5.2, I believe that is making use >> of DCR instrumentation. Currently, I am working with Grinder 3.4, your >> references are only applicable to versions > 3.4. >> >> Here is what I get with Grinder 3.4 with Jython 2.5.2: >> >> 5/30/12 10:58:05 AM (process 1352199-0): elapsed time is 10 ms >> 5/30/12 10:58:05 AM (process 1352199-0): Final statistics for this >> process: >> Tests Errors Mean Test Test Time TPS >> >> Time (ms) Standard >> >> Deviation >> >> (ms) >> >> >> (Test 1 9 0 211.11 451.53 >> 900.00) "BDT Environment Initialisation" >> Test 2 8 0 237.50 472.33 800.00 >> "Login to BDT application" >> >> Totals 8 0 237.50 472.33 800.00 >> >> (9) (0) >> >> >> Here is what I get with Grinder 3.4 and Jython 2.2.1 >> >> 5/30/12 8:57:03 AM (process 1352199-0): Final statistics for this >> process: >> >> Tests Errors Mean Test Test Time >> TPS >> >> Time (ms) >> Standard >> >> >> Deviation >> >> >> (ms) >> >> >> >> Test 1 1 0 0.00 0.00 142.86 >> "BDT Environment Initialisation" >> >> Test 2 1 0 1424.00 0.00 >> 142.86 "Login to BDT application" >> >> >> Totals 2 0 712.00 712.00 142.86 >> >> >> Is there a way in Grinder 3.4 to select which methods of an object are >> instrumented? >> >> Thanks, >> >> Ouray >> >> On Wed, May 30, 2012 at 10:57 AM, Philip Aston <ph...@ma...> wrote: >> >>> Are you using the DCR instrumentation, or the "traditional" >>> instrumentation? >>> >>> There have been a stack of fixes to DCR in recent versions, not least >>> the ability to select which methods of an object are instrumented: >>> http://grinder.sourceforge.net/g3/script-javadoc/net/grinder/script/Test.html#record%28java.lang.Object,%20net.grinder.script.Test.InstrumentationFilter%29 >>> >>> - Phil >>> >>> >>> On 30/05/12 15:52, Ouray Viney wrote: >>> >>> Hi Philip: >>> >>> All great questions, let me try to answer them. >>> >>> On Wed, May 30, 2012 at 10:48 AM, Philip Aston <ph...@ma...> wrote: >>> >>>> Ouray, >>>> >>>> I'm not sure I understand your question. If you had instrumentation >>>> disabled in 3.2, then to what are you comparing the success rate? >>>> >>> >>> For example, with instrumentation disable, we would only see 1 Success >>> per thread per iteration when Logging in to the application. Now, we see >>> every reference to the Java login object added to the Success rate. >>> >>> >>>> >>>> When you say "control" - what are you looking to do: use the script to >>>> check the response, and alter the test result, or something else? >>>> >>> >>> For example, I only want to show the initialization of the Java object >>> and not every reference to it. I have been playing with the Grinder >>> statistics API, but I haven't got what I want *yet*. >>> >>> >>>> >>>> Also, why not 3.9.1? >>>> >>> >>> >>> Until I resolve the aforementioned issue, I don't want to upgrade to >>> 3.9.1 yet, as I would have to resolve double bindings to Logback as the >>> Java client side stubs use logback as well. I issue at a time ;-). >>> >>> Thanks, >>> >>> Ouray >>> >>> >>>> - Phil >>>> >>>> On 30/05/12 15:33, Ouray Viney wrote: >>>> > Hi All: >>>> > >>>> > I am working on upgrading a Grinder performance script originally >>>> > written in Grinder 3.2 (Jython 2.2.1), where instrumentation was >>>> disabled. >>>> > >>>> > I uplifted the Grinder version to 3.4 and noticed the first issue. >>>> > The Success counters were unusually high. That is not desired, as I >>>> > want to maintain the stats gleaned when running with Grinder 3.2. >>>> > >>>> > So, my question is, what is the correct way to manage/control >>>> > Instrumentation statistics when Instrumenting Java code in a Jython >>>> > Grinder performance script? >>>> > >>>> > Let me know if you need more details. >>>> > >>>> > -- >>>> > Ouray Viney >>>> > http://www.viney.ca >>>> > >>>> >>>> >>> >>> >> > > > -- > Ouray Viney > http://www.viney.ca > -- Ouray Viney http://www.viney.ca |