All the work before was just there to get a nice graph model that feels more natural. Now comes the analysis part: As mentioned in the introduction, we don’t only want the hotspots that signal that something awkward happened, but also
the trigger in our application of the hotspot combined with
the information about the entry point (e. g. where in our application does the problem happen) and
(optionally) the request that causes the problem (to be able to localize the problem)…
I show how I determine the parts of an application that trigger unnecessary SQL statements by using graph analysis of a call tree…
In preparation for a talk about performance optimization, I needed some monstrous amounts of fake data for a system under test. I choose the Spring Pet Clinic project as my “patient” because there are some typical problems that this application does wrong. But this application comes with round about 100 database entries. This isn’t enough at all…
I’m a huge fan of the software analysis framework jQAssistant. It’s a great tool for scanning and validating various software artifacts. But I also love Python Pandas as a powerful tool in combination with Jupyter notebook for reproducible Software Analytics.
Combining these tools is near at hand. So I’ve created a quick demonstration for “first contact” 🙂