Technology has boosted every sphere of life where everyone wants faster applications with relevant information to make their lives easier. A faster system always results in a larger and happier audience which in turn increases the revenue. Development team always prefer to optimize code quality before installing additional hardware for performance improvements. Server logs and GC logs provide a relevant information to optimize the code quality like a list of duplicate call, unwanted call and memory leaks. Traditional approach to review sever logs and GC logs analysis is very time consuming and tedious. Hence, this time we worked on identifying the tools and practices that can help review server logs and analyze GC logs in a better manner to save time. We are hopeful that our findings will not only help in saving the time required to review/analyze the sever logs but also it will provide an efficient way to review server logs.
Keep exploring more on performance testing with our quarterly performance testing newsletters.
“When debugging, novices insert corrective code; experts remove defective code.”
- Richard Pattis
Performance tuning primarily depends upon application code optimization - which is not possible without in-depth analysis of application server logs, database server logs, and GC logs. Let’s discuss the various parameters of reviewing logs that enable us to increase an application’s performance.
Garbage Collection Logs
GC logs provide useful information about how heap memory is utilized by application objects. A poor GC analysis results in back-end issues including poor memory management and lower throughput. Novice QA engineers hesitate to analyze the GC logs due to the following reasons:
A poor application performance may lead to the following long lasting issues:
- Hidden memory leaks
- High memory usage
- Slow application response
- Application crashes
- Lower throughput
- Longer transactions queue
- Expensive fix for older issues
Multiple tools like GCPlot, GCeasy, GCViewer, and JClarity review the GC logs in less time and provide recommendations to fix the issues. Following are the few tools that represent GC data in a pictorial manner for better understating and quick review
- Supports multiple GC log formats
- Provides throughput and latency KPIs value for better analysis
- Provides GC duration and GC pause values for each GC run
- Provides promoted objects' bytes size
- Highlights issues like memory leak or long GC pauses
- Provides GC pauses count including Minimum and Maximum GC pauses
- Provides throughput value
- Pictorial representation of heap memory usage
- Provides full GC ran count
- Supports multiple GC log formats
Application Server Logs
The application server log is the face of an application. It contains every information from front-end request to back-end requests' details. Reviewing the heavy server logs is very tedious and time consuming. Following are some common challenges in reviewing application server logs:
- How to get a particular request detail from a lengthy server log?
- How to get subsequent requests of a particular transaction?
- How to filter duplicate requests of a particular transaction?
- How to wrap end points with custom name to be reflected in server logs for easy identification?
- Break down response time chart of a particular transaction
Multiple tools are available to view traces quickly and in an efficient manner like New Relic, Web Transaction Watcher, and Glowroot. Here is a list of common solutions provided by trace viewers like Glowroot:
- Trace capture for slow requests and errors
- Easy to identify a list of duplicate calls
- Capture logs based on Log4j properties settings
- Provision to give customized names for transactions to be reflected in server logs
- Response time breakdown and percentile charts
- Capture SQL along with queries response time
- Historical data to refer in future
- Provides async requests support
- Support multiple application servers like Tomcat and TomEE
- Provide end-to-end logs in case of an issue
- Always share failure transactions to save time
- Report every back-end exception irrespective of UI issue
- Set logging level to ERROR to track back-end issues
- Take sign off on JVM settings
We would love to hear your feedback, questions, comments and suggestions. This will help us to make Perfcast better and more useful next time.
Share your thoughts and ideas at firstname.lastname@example.org