JProfiler Get rid of your performance problems and memory leaks! Modern Garbage Collection Tuning Java Performance Training Courses COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs Java Performance Tuning, 2nd ed The classic and most comprehensive book on tuning Java Java Performance Tuning Newsletter Your source of Java performance news. Subscribe now! Enter email: Training online Threading Essentials course JProfiler Get rid of your performance problems and memory leaks!

Back to newsletter 218 contents

https://www.youtube.com/watch?v=S-awUjTOK60
How to analyze the most common performance problems in Java (Page last updated June 2018, Added 2019-01-27, Author Jack Shirazi, Publisher Java2Days). Tips:

• Having a bottleneck is not a problem, because there is always a bottleneck (otherwise it takes no time at all). Failing to achieve targets is the problem - which means you need targets to know if you have a problem.
• About half of configuration issues that cause problems can be eliminated by manually diffing the new deployment and the current deployment and finding obviously erroneous configuration changes.
• For datastores, indexes always matter, caching in memory always makes it faster, faster disks always makes it faster, the schema matters enormously
• For individual queries that take a long time, improve the query. This likely needs an index or schema change.
• If you find multiple queries that are identical, ask: is it an inefficiency? Can they be cached or reduced in frequency?
• If you find multiple queries that differ only in a parameter, can they be combined or use a parametrized query?
• External requests are always more expensive than logging that request, so so log them all with timing for analysis. Look for individual requests with large times - these are inefficient requests; Look for lots of entries on the same connection and with very close timestamps, these are "chatty requests" and should be combined or simplified; Look for lots of individual big times across many unrelated requests over a time window - these show the external server is overloaded.
• You absolutely MUST monitor the waiting time to acquire the connection from any connection pools.

https://medium.com/hotels-com-technology/optimizing-your-server-by-limiting-request-overheads-e2ddc25d25e5
Optimizing your server by limiting request overheads (Page last updated January 2019, Added 2019-01-27, Author Jack Shirazi, Publisher Hotels.com). Tips:

• There are 3 legs to managing successful servers: make each server more efficient; scale your servers horizontally; and limit the impact of each request
• The business processing needed to satisfy a request is the only essential processing, everything else - including marshaling and unmarshaling data, and sending over the network - is overhead which you want to minimize.
• For requests that have different overheads (eg because some return much more data than others) create different APIs or APIs with different parameters, and make sure that the cost to the client is clearly differentiated for making the request that has higher overhead (higher latency, higher memory, etc) so that clients prefer the lower overhead requests.
• Minimize the size of the data transferred: consider compression, minifying, binary format, and a shared dictionary (lets you send codes rather than constants eg A stands for "fieldname1", B for "fieldname2", etc).
• Paginate and/or lazily Populate the data. The choice of chunk size to send is a balance between the number of additional requests this generates and the amount of unnecessary data transferred.
• Streaming data can be very efficient and is especially optimal where the data can be consumed as a stream

https://www.youtube.com/watch?v=DTHf-0IM8HE
A practical approach to Java Memory Model (Page last updated November 2018, Added 2019-01-27, Author Andrzej Czarny, Publisher JDD). Tips:

• Inlining and code reordering (at both the compiler and hardware levels) can completely change the order of updates and accesses from what you might expect, if you don't use Java concurrency control to enforce ordering.
• Use the JCStress tool to test threaded microbenchmarks to check for correct concurrency control.
• Code against the Java memory model specification, and be aware that different hardware have different memory strengths - eg x86 has a strong memory model but ARMv7 has a weak one so things that seem to run correctly on x86 can have race conditions that show up on other hardware.
• Don't create threads in your constructor, or let anything being constructed in the constructor be externally accessible (before the constructor is finished) as that is a race condition.
• Avoid low-level concurrency control (eg volatile) except where you absolutely have to, as the code can be fragile and maintenance changes can easily break the correct concurrency control.
• Use final with immutable classes.

https://www.youtube.com/watch?v=I5gYIso37dk
High-performance libraries in Java (Page last updated December 2018, Added 2019-01-27, Author Peter Lawrey, Publisher IT Days). Tips:

• Fast concurrent message processing: CAS to acquire a lock & reserve uncontended space to write in to, write, CAS to release the lock and show it's ready for reading
• Ensure that a critical low latency thread is never blocked, offload any blocking processing onto other threads.
• Beyond 99.99% latency measurements at low latency, your hardware becomes more important than the software.
• Keeping message size below 60 bytes is useful as that fits in a cache line.
• A queue is useful if you need the full set of data, but if you just want the latest value a Map is ideal.
• If just one in 400 CPU operations on a 20 core system needs to go to L3 instead of L1, you've doubled the cost of memory access
• Use textual readable format for messages in testing but binary in production with a mapper that lets you view the binary as text.

Jack Shirazi Back to newsletter 218 contents