Java Performance Tuning
Java(TM) - see bottom of page
Our valued sponsors who help make this site possible
JProfiler: Get rid of your performance problems and memory leaks!
Training online: Concurrency, Threading, GC, Advanced Java and more ...
Tips November 2021
JProfiler
|
Get rid of your performance problems and memory leaks!
|
JProfiler
|
Get rid of your performance problems and memory leaks!
|
|
|
Back to newsletter 252 contents
https://www.youtube.com/watch?v=P1zJwRkat6s
Tradeoffs, Bad Science, and Polar Bears: The World of Java Optimisation (Page last updated November 2021, Added 2021-11-29, Author Holly Cummins, Publisher Accento). Tips:
- Faster responses correlate directly to revenue in many industries, especially for online trading, and for websites that generate revenue from their web presence.
- Useful performance measures include: throuput (transactions/requests per second); response time; start-up time; ramp-up time; footprint; CPU usage.
- In the cloud, the footprint matters and is most likely the limiting factor in minimizing cost of a JVM application.
- A significant fraction of workloads (30% by some estimates) are "zombie" workloads which are using resources but are no longer needed - they just have been forgotten to be removed!
- Repeatedly compacting during GCs is bad for minimizing pause times, but good for optimizing throughput.
- Useful performance advice: GCs can improve performance (by rearranging the heap); find the bottleneck (tuning anything else is a waste of effort); Validate advice as it can be out of date (or wrong).
- Out of date advice include: making big methods; reusing objects; particular command line options are more effective; use StringBuilder for concatenation.
- Almost all the time, readability is more important than performance.
- clean and typical code is optimized much better by the JVM than strange looking code.
- outliers matter more than averages sometimes - it depends on which impacts the customers more.
- there is a moral imperative to minimize energy and hardware use, to help the world.
https://www.youtube.com/watch?v=4jlfd3XCeTM
Interesting Garbage collection patterns (Page last updated October 2021, Added 2021-11-29, Author Ram Lakshmanan, Publisher yCrash). Tips:
- A healthy application has a GC pattern which is a saw-tooth GC pattern with tops and bottoms of the saw-tooths at consistent values. If the bottom value is a large memory value, this could indicate caching a lot - perhaps too much, and a memory analysis might help to reduce this.
- A continuous memory leak typically shows a GC pattern with the heap after GCs gradually and continuously increasing.
- A sequence of full GCs very close together (consecutive full GC) is indicative of heap being too small, or a memory leak. If the heap recovers to a lower value, it could have been a traffic spike.
- A sudden spike in memory use followed by continuous full GCs is indicative of memory leak triggered by something.
https://www.youtube.com/watch?v=36t5OLLzA6c
No GC coding techniques for low latency Java (Page last updated November 2019, Added 2021-11-29, Author Ivan Zvieriev, Publisher JDD). Tips:
- Latency causes: slow external resources (like db calls); inefficient algorithms; inefficient data structures; communications; JVM activities.
- Singletons are by definition reused, so are useful for low latency no-gc coding. They have issues, Enums are a good solution to any of the problems.
- The flyweight pattern (using static methods to create objects, potentially using a cached instance) reduces object creation/memory consumption so are useful for low latency no-gc coding.
- presizing collections to their largest used size eliminates object copying from collection resizing so are useful for low latency no-gc coding.
- Primitive type collections avoid object boxing/unboxing so are useful for low latency no-gc coding.
- Using StringBuilder instead of Strings eliminates many String object creations so are useful for low latency no-gc coding.
- Enums instead of Strings eliminates creating many String copies so are useful for low latency no-gc coding, but avoid Enum.values().
- guard logging statements (if(log.level == DEBUG) ...) eliminates creating unneeded objects so are useful for low latency no-gc coding.
- Reusing objects reduces object creation so are useful for low latency no-gc coding, but you now have mutable objects so you have to handle the concurrency issues.
- Desigining each service as single-threaded is useful for low latency no-gc coding.
Jack Shirazi
Back to newsletter 252 contents
Last Updated: 2025-01-27
Copyright © 2000-2025 Fasterj.com. All Rights Reserved.
All trademarks and registered trademarks appearing on JavaPerformanceTuning.com are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. JavaPerformanceTuning.com is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
URL: http://www.JavaPerformanceTuning.com/news/newtips252.shtml
RSS Feed: http://www.JavaPerformanceTuning.com/newsletters.rss
Trouble with this page? Please contact us