wuqiSpank

UPDATE:  October 12, 2014.  Check out http://wuqiSpank.org for the latest release of wuqiSpank.

  Yep, that's the name of the monitoring application that I'm writing.  wuqi.  spank.  wuqispank. 

• Is your code SELECTing data from the exact same table multiple times in a single request?  
• How many round trips does your code make to the database?  
• Re-executing the exact same SELECT statement?

There are all kinds of performance efficiencies to be gained by refactoring this kind of code.
I'm working on a monitoring tool that will visually answer the above questions by graphing your applications' SQL activity.  wuqi = woefully unnecessary query invocation.  Spank those wuqi's.

Here are some of the milestones in writing this monitoring application:

1. The first step is to get a headless monitoring API that will allow me to write java code that will get notified when SQL statements get executed on a remote JVM.  InTrace is a great tool for tracing all JVM method invocations, but the GUI is very tightly integrated with the event API....until now: this headless version of the InTrace API let's you write monitoring tools to collect events from remote (or local) JVMs.
2. What code of mine executed this particular SQL statement?  To answer this question, wuqispank will need to have stacktrace information for all SQL statements.  Need to be able to configure the InTrace agent to send back stacktraces for all (perhaps selected) method calls.
3. All those stacktraces will take up a lot of bandwidth.  This InTrace enhancement is a fork of the main InTrace repo.  It adds GZIP compression to the network events transmitted over the wire.
4. Need to write a web application that uses the headless InTrace API to graphically display SQL activity....