SFR Performance

Hi, welcome to Jennifer Application Performance Management. At this moment, we'll proudly introduce a new improvement feature in Jennifer, and we call it Stacktrace Flight Recorder or SFR. SFR is used for performance analysis based on Stacktrace, which can improve the performance of an application with less resource usage. SFR focuses on the entire method performance of an application. SFR is the enhancement of the Stacktrace feature in the XView Profile function. It's a dedicated screen that can be accessed from the Analysis menu. SFR can retrieve Stack information collected after installing the Jennifer agent on the data server. SFR consists of three components. The Flamescope, the top method, and the FlameGraph. Let's roll into Flamescope first. Flamescope is a chart with many red squares at the top part of the screen. The X-axis and the Y-axis of the Flamescope chart determine the passage of time, where each square represents one minute of stacks collected. The red color shows how many stacks that fell in the time range. The higher the n The less the n If we drag an area with a darker color within a time range, we're more The second component is the top method. The top method indicates the distribution of the methods running at the time the stack trace is collected. If you see a user created or familiar method here and have a higher percentage, the method is Suppose we reduce the frequency with which a method appears at a noticeably higher percentage, either improving performance or finding and replacing better alternatives, in that case, we can drive a performance boost in our application. The last component is the FlameGraph. The FlameGraph visualized the call relationship of each stack trace based on the selected area in the Flamescope. The top of the stack represents the beginning of the stack, and the progress towards the bottom of the stack indicates the progress of the call till the progress ended. The different colors in the FlameGraph indicate the different application packages. As mentioned before, we can use SFR to do analysis based on stack trace, and it will pinpoint which method is The following screen is an example of the SFR screen after performing a search and finding the method that causes a problem. After roughly dragging the red part, we can see that most of the time it took to read random access file based on the contents indicated in the top method. The rest of the wide area, except for reading the file appears as abstract record dot to object db. The sub methods are realtime object record dot red, which reads the bytes from the input stream in a predetermined order and converts them into objects. This part occupies 19. 05% of the total. First attempt to improve it, instead of handling the bytes using input stream, I've implemented it using byte buffer. Then here is how the SFR screen will be, after improving it. The red color on the Flamescope is lighter after the improvement is made. It implies that the time of the call requested takes a shorter time. The FlameGraph at the bottom shows that the abstract record to object db has been reduced to 9. 03%. N Then, I try to read it using a memory map on the second attempt. Now we can also see very little random access related content in the top method. So that was a brief explanation about the SFR or StackTrace flight recorder. We look forward to seeing how the features implemented this time can help with performance analysis as a complementary relationship to traditional profiling-centric analysis. See you again in the upcoming videos. Thank you.