I love it! More features and less code for us to maintain. Zach On Jul 9, 2012, at 8:46 AM, Branden Visser wrote:
> Just a quick follow-up about this. > > With a bit of polishing, I think this is ready for a PR, I've created > a ticket that will hopefully track a PR for 1.5 [1]. I've put together > a screencast demo [2] of how to use it nakamura, and have started some > documentation [3]. > > If this can be enabled in production, I think we could use it to track > our telemetry and slow query logs as well, and do away with our custom > telemetry code. To start, I've dropped in perf4j profiling in every > spot that we currently have telemetry and slow query logging. This > enhances all our telemetry hotspots with timing. > > [1] https://jira.sakaiproject.org/browse/KERN-3001 > [2] http://www.screencast.com/t/GSGKpVyae > [3] https://oae-community.sakaiproject.org/content#l=id7737393&p=mHywyCkM2b > > On Mon, Jul 2, 2012 at 8:50 AM, Branden Visser <[email protected]> wrote: >> On Mon, Jul 2, 2012 at 2:56 AM, Berg, Alan <[email protected]> wrote: >>> 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. >> >> The log processing tool provided by the perf4j binary would be a good >> start, and may be all the information we really need with respect to >> timing [1]. Also, we should be able to tap in to the functionality of >> the graphing servlet [2] to get real-time performance stats. >> >> [1] >> http://perf4j.codehaus.org/devguide.html#Parsing_Log_Files_to_Generate_Performance_Statistics >> [2] >> http://perf4j.codehaus.org/devguide.html#Writing_Graphs_with_the_GraphingStatisticsAppender >> >>> 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 >> >> >> >> -- >> Cheers, >> Branden > > > > -- > 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
