Pre-defined number of users in OLB-database scope

[tormoseng]

When testing the the database scope in OLB, the code overrides my settings from the DynamicSpotter. Happens in OLBDetectionController.java (see below). Any good reason for this?

@OverRide
public void executeExperiments() throws InstrumentationException, MeasurementException, WorkloadException {
if (!reuser) {
// TODO: fix that
if (scope.equals(OLBExtension.DB_SCOPE)) {
instrumentApplication(getInstrumentationDescription(1.0));
runExperiment(this, 1);
uninstrumentApplication();

            instrumentApplication(getInstrumentationDescription(1.0));
            runExperiment(this, 125);
            uninstrumentApplication();

            instrumentApplication(getInstrumentationDescription(0.1));
            runExperiment(this, 250);
            uninstrumentApplication();

            instrumentApplication(getInstrumentationDescription(0.1));
            runExperiment(this, 375);
            uninstrumentApplication();

            instrumentApplication(getInstrumentationDescription(0.05));
            runExperiment(this, 500);
            uninstrumentApplication();
        } else {
            executeDefaultExperimentSeries(this, experimentSteps, getInstrumentationDescription());
        }

    }
}

[tormoseng]

Why can't we just use code below instead?

@OverRide
public void executeExperiments() throws InstrumentationException, MeasurementException, WorkloadException {
if (!reuser) {
executeDefaultExperimentSeries(this, experimentSteps, getInstrumentationDescription());
}
}

[tormoseng]

I can see that the getInstrumentationDescription()-method sets the granularity to fine-grained for DB_SCOPE, but this is not set for the other scopes. Maybe there is something here about finding the appropriate granularity level?

And what does the Nop.Web.Controllers.ShoppingCartController:ProblemMethod mean for the SYNC_SCOPE in the same method?

[snowball77]

I do not see any good reason for this. However, the code modifies the
number of users and the granularity together. The latter defines which
fraction of threads passing the probes in an instrumentation scope are
recorded. For example, the code below increases the load while
simultaniously decreasing the number of samples taken (I guess this is
not to overload the system with the monitoring overhead).

Am 05.10.15 um 13:01 schrieb Tor M:

When testing the the database scope in OLB, the code overrides my
settings from the DynamicSpotter. Happens in OLBDetectionController.java
(see below). Any good reason for this?

@OverRide https://github.com/Override
public void executeExperiments() throws InstrumentationException,
MeasurementException, WorkloadException {
if (!reuser) {
// TODO: fix that
if (scope.equals(OLBExtension.DB_SCOPE)) {
instrumentApplication(getInstrumentationDescription(1.0));
runExperiment(this, 1);
uninstrumentApplication();

|instrumentApplication(getInstrumentationDescription(1.0));
runExperiment(this, 125); uninstrumentApplication();
instrumentApplication(getInstrumentationDescription(0.1));
runExperiment(this, 250); uninstrumentApplication();
instrumentApplication(getInstrumentationDescription(0.1));
runExperiment(this, 375); uninstrumentApplication();
instrumentApplication(getInstrumentationDescription(0.05));
runExperiment(this, 500); uninstrumentApplication(); } else {
executeDefaultExperimentSeries(this, experimentSteps,
getInstrumentationDescription()); } } } |

—
Reply to this email directly or view it on GitHub
#45.

Prof. Steffen Becker
Professur Softwaretechnik
Angewandte Informatik

Technische Universität Chemnitz
Straße der Nationen 62 | R. B216B
09111 Chemnitz
Germany

Tel: +49 371 531-36144
Fax: +49 371 531-836144

[email protected]
www.tu-chemnitz.de

[snowball77]

This would not modify the granularity. You could test this and see
whether the monitoring overhead remains small.

Am 05.10.15 um 13:10 schrieb Tor M:

Why can't we just use code below instead?

@OverRide https://github.com/Override
public void executeExperiments() throws InstrumentationException,
MeasurementException, WorkloadException {
if (!reuser) {
executeDefaultExperimentSeries(this, experimentSteps,
getInstrumentationDescription());
}
}

—
Reply to this email directly or view it on GitHub
#45 (comment).

Prof. Steffen Becker
Professur Softwaretechnik
Angewandte Informatik

Technische Universität Chemnitz
Straße der Nationen 62 | R. B216B
09111 Chemnitz
Germany

Tel: +49 371 531-36144
Fax: +49 371 531-836144

[email protected]
www.tu-chemnitz.de

[snowball77]

Am 05.10.15 um 13:18 schrieb Tor M:

I can see that the getInstrumentationDescription()-method sets the
granularity to fine-grained for DB_SCOPE, but this is not set for the
other scopes. Maybe there is something here about finding the
appropriate granularity level?
I agree, the current code seems to be an arbitrary heuristic.

And what does the
Nop.Web.Controllers.ShoppingCartController:ProblemMethod mean for the
SYNC_SCOPE in the same method?
This is special code which applies to the TPCW usecase. I think it
should not be in the general extension code, but rather in a TPCW
specifc extension.

—
Reply to this email directly or view it on GitHub
#45 (comment).

Prof. Steffen Becker
Professur Softwaretechnik
Angewandte Informatik

Technische Universität Chemnitz
Straße der Nationen 62 | R. B216B
09111 Chemnitz
Germany

Tel: +49 371 531-36144
Fax: +49 371 531-836144

[email protected]
www.tu-chemnitz.de

[tormoseng]

Good answers as always! So the granularity actually refers to the sampling amount, e.g. getInstrumentationDescription(1.0) means 10 times more sampling than getInstrumentationDescription(0.1).

I'm trying to understand (parts) the code in order to know what the DynSpotter actually can do for me. In my pursuit I have come up with 4 more questions:

1. The string "Nop.Web.Controllers.ShoppingCartController:ProblemMethod" are placed as as name instead of X.class.getName(). Are there no scope-artifact-class that fits for the SYNC-scope in package org.aim.artifacts.scopes (in where both the ENTRY- and DB-scopes have classes)?
2. I can see from org.aim.description.scopes that there actually are several more scopes to consider. Which one should actually find our "developed" classes in our use case (i.e. those in the no.kantega-package)? Maybe the reason the agent does not pick up our classes is due to the use of wrong scope-class from org.aim.description.scopes?
3. Also, why isn't SYNC-scope using org.aim.description.scopes.SynchronizedScope?
4. Not the most important question at the moment, but could I track also memory by adding the line
   idBuilder.newSampling(MemoryUsageSampler.class.getName(), SAMPLING_DELAY);
   in method OLBDetectionController.getInstrumentationDescription()?

[snowball77]

Am 05.10.15 um 14:54 schrieb Tor M:

Good answers as always! So the granularity actually refers to the
sampling amount, e.g. getInstrumentationDescription(1.0) means 10 times
more sampling than getInstrumentationDescription(0.1).
Exactly! This means on average only every tenth thread is recorded.

I'm trying to understand (parts) the code in order to know what the
DynSpotter actually can do for me. In my pursuit I have come up with 4
Great! I have already understood large parts of it, in particular in AIM
as I refactored large parts of it. You can see my endevour in the branch
called jmx-agent in all four relevant projects.

It is about to be released as test version. I have changed the
communication between Spotter and Agent to use now JMX instead of Json.
This minimizes conflict betweem Agent classes and Application classes.
Furthermore, I have improved performance of the agent already
significantly. And it should be better able to deal with multiple class
loaders. I will post instructions, as soon as we have also a working
problem hierachy for it.

more questions:

The string
"Nop.Web.Controllers.ShoppingCartController:ProblemMethod" are
placed as as name instead of X.class.getName(). Are there no
scope-artifact-class that fits for the SYNC-scope in package
org.aim.artifacts.scopes (in where both the ENTRY- and DB-scopes
have classes)?

Entry and DB Scope are specific instances of so called API scopes. I.e.,
they instrument all methods belonging to a certain API. Those methods
are predefined by the respective classes. Either by stating the
class+method signatures belonging to the API or by enumerating Java
annotations which mark certain methods as belonging to an API.
EntryScope selects all methods belonging the the servlet API and DB
scope select all java.sql methods.

A method scope is on the other hand the parent concept of the API scope,
where you can define the methods of interest in a freestyle way by
specifiying a list of methods including placeholders like "*" which
should be instrumented. I do not know exactly which method is
instrumented by
"Nop.Web.Controllers.ShoppingCartController:ProblemMethod" as I do not
yet understand the ":" placeholder. However, you can see other examples
in the code above that line which is more intuitive.

Now finally, I do not understand what the SYNC scope was supposed to do.
Intuitively it sounds if all synchronized methods or blocks should get
instrumented. I assume the code in the SYNC scope case is simply
nonsense and a relict of some playing around with the code. Anyhow, the
code seems not to be generalised but has been written specifically for TPCW.

I can see from org.aim.description.scopes that there actually are
several more scopes to consider. Which one should actually find our
"developed" classes in our use case (i.e. those in the
no.kantega-package)? Maybe the reason the agent does not pick up our
classes is due to the use of wrong scope-class from
org.aim.description.scopes?

As explained in 1.) you could try to use a method scope and put there as
string for example "no.kantega*". This would actually instrument all
methods in all Kantega classes, which might result in quite a lot of
measurements.

There are more sophisticated scopes in AIM which I just begin to
understand. If you know the entry method of your application, a
TraceScope might be interesting for you. This is a bit long to explain
here, we could Skype about it.

Also, why isn't SYNC-scope using
org.aim.description.scopes.SynchronizedScope?

Simple answer: This scope - AFAIK - is not implemented. There is no
ScopeAnalyzer matching it. A ScopeAnalyzer converts a scope into a list
of classes and their methods to instrument. I assume this is simply not
yet supported. In case synchronized methods are interesting for you we
could try to define a scope for it by providing a matching extension.
However, this is only useful if you really have them in your code base.

Not the most important question at the moment, but could I track
also memory by adding the line
idBuilder.newSampling(MemoryUsageSampler.class.getName(),
SAMPLING_DELAY);
in method OLBDetectionController.getInstrumentationDescription()?

Indeed!

However, this would make more sense in a child detector of the Ramp
which could detect ever increasing memory demands of your application.
This has to be developed as I don't see it somewhere at the moment.

—
Reply to this email directly or view it on GitHub
#45 (comment).

Prof. Steffen Becker
Professur Softwaretechnik
Angewandte Informatik

Technische Universität Chemnitz
Straße der Nationen 62 | R. B216B
09111 Chemnitz
Germany

Tel: +49 371 531-36144
Fax: +49 371 531-836144

[email protected]
www.tu-chemnitz.de