A nice experiment. Has potential.

So, we would have a different maven profile for demo and production so that any 
overhead for keeping track goes away in production. If we could agree how to 
make parsing easy then we could profile on Jenkins with  some Jmeter plans 
hitting the code and then the logging parsed by simple scripts. And in 
combination with the telemetry and the slow queries log you should be able to 
have a 360 degree view without running detailed performance tests.

Success depends on logistics, how much work, overhead, developer time etc.

Cool.

Alan Berg

Group Education and Research Services
Central Computer Services
University of Amsterdam

________________________________________
From: [email protected] 
[[email protected]] on behalf of Branden Visser 
[[email protected]]
Sent: 02 July 2012 06:40
To: [email protected]
Subject: [oae-dev] perf4j

Hi everyone,

I spent some time this weekend checking out perf4j [1] to see if it
can provide any useful profiling information for us. I particularly
liked the idea of getting timing data, and it seemed to have some nice
ways to do it. So here is a summary of the experiment.

First of all, here is the code: https://github.com/mrvisser/nakamura/tree/perf4j

I used the annotation-based profiling tag [2][3], that tells perf4j
that a particular method is to be profiled, which means whenever it is
executed, there will be a log entry that shows the tag and how long it
took the method to complete. It has a syntax that will let you
dynamically specify a "tag" string based on input args, output values,
and method names. This can be thought of in the same way as telemetry,
where we can increment a counter based on some arbitrary "tag" string.

I used the AspectJ maven plugin to perform compile-time weaving which
injects the performance data logging logic, and the weaving is
activated by a maven profile 'perf4j' [4].

There is a perf4j bundle [5] that I put together (it is just a pom.xml
file) to expose the necessary dependencies. Some of these (e.g.
aspectj) can be split into their own bundles, but having better
control over package imports was helpful for now.

So far it has been a success (or else I would have banished the branch
into the dark ether to never be compiled again!). It outputs. Next, I
would like to make the logging more configurable and try and get the
graphing servlet running.

As of now, I could see this profiling being enabled for QA servers and
performance test environments, but would like to see its performance
characteristics (and how useful it becomes) before making it default.
It is still a work in progress, but wanted to get an early version out
to gather thoughts and suggestions.

[1] http://perf4j.codehaus.org/
[2] 
http://perf4j.codehaus.org/devguide.html#Adding_the_Profiled_Annotation_to_Method_Declarations
[3] 
https://github.com/mrvisser/nakamura/blob/perf4j/bundles/connections/src/main/java/org/sakaiproject/nakamura/connections/ConnectionManagerImpl.java#L214
[4] https://github.com/mrvisser/nakamura/blob/perf4j/pom.xml#L365
[5] https://github.com/mrvisser/nakamura/tree/perf4j/bundles/perf4j

--
Cheers,
Branden
_______________________________________________
oae-dev mailing list
[email protected]
http://collab.sakaiproject.org/mailman/listinfo/oae-dev
_______________________________________________
oae-dev mailing list
[email protected]
http://collab.sakaiproject.org/mailman/listinfo/oae-dev

Reply via email to