Introduction in Trace Compass:
Trace Compass is an open-source application performance analysis framework. It is designed to visualize and analyze traces, which are recordings of events that occur in a software system during its execution. Trace Compass is particularly useful for understanding complex software systems' behavior, performance, and interactions.
Key features of Trace Compass include:
1) Trace Visualization: It provides a graphical representation of traces, allowing users to visualize the sequence and timing of events in a system.
2) Analysis Tools: Trace Compass offers various analysis tools and modules for different types of traces, helping users identify performance bottlenecks, errors, and other issues.
3) Support for Multiple Trace Formats: It supports various trace formats from different sources, making it versatile for analyzing traces generated by various software components.
4) Customizable Views: Users can customize the views and analyses based on their needs, allowing for a more tailored and effective analysis process.
5) Integration with Eclipse: Trace Compass is often integrated with the Eclipse IDE, providing developers with a seamless environment for analyzing and debugging their applications.
Overall, Trace Compass is a valuable tool for developers, system administrators, and performance analysts to gain insights into the runtime behavior of software systems and optimize their performance.
The problem:
If the Trace Compass server is located remotely and handles bulky responses, it could pose a throughput problem for the server channel.
In particular, for certain charts with high data density, such as the example below, the front end will request more events as the user's screen resolution increases. In the given example, it requests 3441 events based on the current user screen resolution (e.g. min(max_number_of_events_in_the_given_time_range, 3441)). If the user had a resolution of 2560x1440, the request would encompass an even higher number of events. With each zoom-in/out, the client initiates a request for a new data portion, and caching these responses does not make sense. This is because, for individual users, each zoom-in/out action is unique, reflecting their personalized debugging of the trace. Additionally, users are unlikely to repetitively perform zoom-in and zoom-out actions in a predictable pattern.
Comparison with Text JSON and GZip JSON for large traces:
Following an analysis of the responses, it is clear that each one harbors a substantial volume of duplicated data, exemplified by instances like [...{"event_start": /timestamp/, "event_end": /timestamp/, "event": "..."}...]. This recurring structure indicates the response's aptness for compression, given the repetitive nature of the fields. Notably, numerous "event_start" and "event_end" values represent timestamps with minimal differences, primarily from the right side. Consequently, the distinctions among these timestamps are confined to a few numerical values. The same principle holds true for "events" since there exists a finite number of them in each trace.
Two requests were demonstrated below for the same zoom level—one for JSON (referred to as Text JSON in the article) and the other for JSON with GZip compression (referred to as GZip JSON). As observed, the compression rate exceeds 10 times, attributable to the repetitive structure of the fields and values.
Profiling Trace Compass with Trace Compass
Trace Compass allows one to create its own trace and after that one can download the result in Trace Compass for future analysis. To do it in Linux, it requires:
Create a directory ~/.tracecompass/logs
Run Trace Compass with the following JVM arguments:
-Djava.util.logging.config.file=<PATH_WHERE_TRACE_COMPASS_IS_LOCATED>/logging.properties -Dorg.eclipse.tracecompass.logging=trueExecute desired actions
In ~/.tracecompass/logs will be created a new file trace_0.json
Transform this trace_0.json with `jsonify.sh` that is as well inside the directory where one cloned TraceCompass
Download the output of `jsonify.sh` in Trace Compass
Create a new Tracing Project -> open it -> right click on ‘Traces” -> open trace -> choose the output of `jsonify.sh` -> open it -> Views -> Thread by components -> Flame Chart Incubator
The purple line here represents the time of execution of the business logic and the blue one is the time of Serialization.
In this example, the total time of the business logic is 1.18 seconds (47.5% of the full highlighted area the execution time of logic + Serialization) and the total time is 2.49 seconds (can be seen at the bottom of the screen)
The total time of the execution of the business logic + Serialization here is about 1.58 seconds and the total time of Serialization is 0.59 seconds.
GZip in this case significantly decreases the time required for the Serialization part. Most of the work occurs when running the business logic. Specifically, it takes 1 second or 62.85% of the total time to run the business logic and Serialization. This is different from Text JSON, where running the business logic takes 1.18 seconds or 47.5% of the overall workload time.
Conclusion:
Because this is an open-source project it is not possible to change the format of API. Considering this fact, we can apply GZip for compressing. In this case, the compression rate exceeds 10 times, attributable to the repetitive structure of the fields and values.
Disclaimer:
When GZip is used, it uses the machine's CPU for compressing. If the server is under heavy load and the bottleneck for the profiling application is the CPU, GZip JSON might end up slower than Text JSON. On the other hand, Text JSON uses RAM.
Authors: Iurii Glushenkov, Ankush Tyagi, Dhruv Motwani
