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 174 contents

http://www.infoq.com/news/2015/03/petabyte-jvms
Peter Lawrey Describes Petabyte JVMs (Page last updated March 2015, Added 2015-05-28, Author Charles Humble, Publisher QCon). Tips:

• JVM memory efficiency drops with heaps over 32GB.
• Rebuilding a dataset will take 2 minutes for 10GB at 100MB/s (close to saturating a gigabit line).
• Heaps below 4GB can use direct addressing. Heaps below 32GB have compressed OOPs on by default, allowing 32-bit references; java 8 allows 32-bit references on 64GB heaps using a factor 16 object alignment. Beyond 32GB (or 64GB for java8+), you have to use 64-bit references which reduces efficiency by a small but consistent amount.
• Large heaps have significant potential pause times, unless you are using a JVM+garbage collector which has small worst case pause times
• Using off-heap memory allows you to store large amounts of data off the heap, so keeping the heap small and so gaining 32-bit and sgort pause efficencies.
• Each CPU socket has "local" access to a bank of memory, however to access another bank, the socket needs to use the bus. This is much slower, particularly for garbage collection (which assumes random access) - so the NUMA region size matters. This depends on the CPU architecture and can be limited to 1TB (40 bits address space) on many modern processors.
• Many chips are limited to a 48bit address space - 256TB. Memory maps can address this space, even if the physical RAM is smaller (the transparently OS handles mapping in the correct memory segments into the physical memory).
• For a petabyte (50-bits) JVM, because of the 48bit address limitation of most current processors, you need to cache memory maps within 256TB segments; and bearing in mind you should restrict the JVM size to one NUMA region this implies multiple JVMs of the size of the NUMA region or less, sahring multiple shared memory segments each of 256TB or less.
• Vertical scaling to petabyte scale (rather than horizontal scaling) is needed if you need local random access.

http://vladmihalcea.com/2015/02/03/how-to-fix-optimistic-locking-race-conditions-with-pessimistic-locking/
How to fix optimistic locking race conditions with pessimistic locking (Page last updated February 2015, Added 2015-05-28, Author Vlad Mihalcea, Publisher vladmihalcea). Tips:

• Race conditions mean you can process some kinds of optimistic transactions with incorrect results. Where you are not using a compare-and-swap type of operation and there is the potential of a race condition, you need to lock to ensure that the transaction operates correctly.

http://www.3scale.net/2015/04/how-to-load-test-and-tune-performance-on-your-api-part-i/
How to load test & tune performance on your API (Part I) (Page last updated April 2015, Added 2015-05-28, Author Victor Delgado, Publisher 3scale). Tips:

• Load tests should have a workload that is as similar as possible to the one that your API will be handling for real. Gather usage data.
• Determine: average & peak throughput (requests per second) per API endpoint; and throughput distribution by users.
• Run tests with (simulated) real traffic (eg from replayed production logs); or if unavailable use repetitive load generation.
• Increase the load to find the point where performance is no longer acceptable, so that you know how far your infrastructure can scale.
• You should have a dedicated performance testing environment similar to production capacity.
• Identify the resource that becomes a bottleneck for your API.
• Establish baselines performances so that you can compare those against subsequent changes.

http://www.javaspecialists.eu/archive/Issue229.html
Cleaning ThreadLocals (Page last updated May 2015, Added 2015-05-28, Author Dr. Heinz M. Kabutz, Publisher The Java Specialists' Newsletter). Tips:

• Avoid ThreadLocal if possible, because when used in a pool (which is increasingly the case) it hangs on to it's references even after the thread is realocated back to the pool. This is a common cause for memory leaks.
• Using an InheritableThreadLocal means that if you construct a new thread from your current thread, all the inheritable ThreadLocals in the creating thread are inherited by the new thread. It's not very useful and potentially a worse source of leaks than a plain ThreadLocal.
• In Java 8 java.util.logging.Logger methods accept a Supplier<String> (as an alternative to a String), which means that you can now pass a Supplier and the resulting code only gets evaluated when the log line is actually emitted - ie you get lazy evaluation and the log entry no longer needs to be guarded to avoid the string getting evaluated if the log level is insufficient to trigger the log line.

http://www.infoq.com/presentations/performance-safety
Stuff I Learned about Performance (Page last updated March 2015, Added 2015-05-28, Author Mike Barker, Publisher InfoQ). Tips:

• Average numbers are almost useless for performance except unless you're batch oriented - outliers matter much more as the outliers show the peak performance that your system needs to handle - or break the SLAs.
• A 200ms remote request pause is indicative of TCP packet loss and retransmissions.
• Focus on the slowest requests and the 99.99% percentiles. Don't oversimplify measurements to one number - provide the details.
• Pay attention to entity life-cycles and how many entities there are.
• Everything is a tradeoff - understand the downsides as well as the upsides.
• Look at the operations, and identify what operations are being executed that don't need to be done for your purposes. Then eliminate those unnecessary operations.
• Efficient parsing should be done in a stream-oriented way, with callbacks when an item needs parsing; leave converting the raw data into object data to the last point of the parsing sequence (if you only create primitive fields, you won't even create any garbage).
• Avoid generating garbage completely if you want to avoid GC pauses. This has significant development and maintenance costs though.
• Design to allow tradeoff choices to be made by implementors/operations.

http://www.informit.com/articles/article.aspx?p=2350706
Performance Advice for Beginning Java Programmers (Page last updated April 2015, Added 2015-05-28, Author Charlie Hunt, Publisher informIT). Tips:

• Performance requirements are very important to capture as early as posible, and the more detailed the requirements, the better.
• Determine the requirement for each of following performance attributes: Throughput (requests/second); Latency (response time); Memory footprint; Concurrent requests or users.
• Define performance requirements for both normal and peak loads. Are there acceptable variances allowed, eg the peaks won't last long but while they occur latency can increase by X amount? How much hardware capacity is available and what are their acceptable utilization levels.
• Determine how the various performance targets will be measured. Measurement of the metrics is one of the most important issues.
• For latency/response time measurements, don't use averages. Use worst cases and various percentiles, eg 90%, 99%, 99.99%. Requirements should correspond to measurements.
• When making measurements, consider that there could be delays outside the measurements, eg when measuring response time, if a request is in the socket queue and a GC pause occurs, the request is not timestamped until after the pause completes (when the application accepts the request from the queue) so it the latency measure will not include the pause time!

Jack Shirazi

Back to newsletter 174 contents