How expensive are your JDBC operations?

It is now a week into our JDBC monitoring private beta program. Things are progressing fast and we expect to be ready to launch publicly within a month. But as the first results are already in, we are eager to demonstrate our initial findings.

First and foremost we have to disclose that the sample set is still small consisting of just couple of hundred JVMs, so you should take the following data with a grain of salt. As more data keeps arriving on daily basis, we expect to publish a more thorough overview in less than a month from now.

First discovery from the data set confirmed our gut feeling – relational datasources are indeed everywhere. We detected JDBC datasources in 95% of the JVMs our JDBC monitoring was turned on.

Next important piece of information is more relevant to our engineering priorities, but at the time of publishing this post, we are able to instrument and monitor 89% of these datasources. The most common reason Plumbr is currently unable to monitor datasources is due to the missing support for JDBC 4.1 drivers. Work in this regard is already in progress and we expect to have polished the support for 4.1 drivers already before the public launch.

The remaining configurations where we detected unsupported datasources expose a variety of different smaller database vendors, support for which will be prioritized and implemented after the public launch.

But where it becomes interesting again is the extent of the slow operations detected. The following chart outlines the percentiles of JVMs regularly launching queries the duration of which exceeds different thresholds:

In order to interpret the data the following examples might help

• 47% of the JVMs regularly execute JDBC operations blocking for five seconds or more.
• 18.5% of the JVMs regularly execute JDBC operations stalling the user transactions for more than 30 seconds.

Notice that we do not yet group the operations into different categories regarding latency requirements, so that some of the following statistics might contain operations which are not violating performance requirements when blocking on IO for extended periods of time.

Nevertheless, based on the initial feedback surfacing this information and grouping such incidents per root cause has already allowed several beta program members to fix performance issues.

If you are uncertain how your JVMs perform in regards of expensive JDBC operations blocking the user transactions and causing poor user experience – join to the private beta program. The queue is served on first-come-first-served basis, so do not hesitate!