Latest news
NEW: SEPTEMBER NEWSLETTER
AUGUST NEWSLETTER
JULY NEWSLETTER
JUNE NEWSLETTER
MAY NEWSLETTER
- We list all the latest Java performance related news and articles
- "if you have any Serverless I really recommend watching this masterclass"
- All the latest Java performance tips extracted in concise form
- "Serverless invocation types: synchronous (request/response; errors returned to and retries required by the client); asynchronous (event sent by client then disconnected; event on a queue for the serverless function, serverless function called N times or M seconds - configurable, dependent on throttling - then sent to dead letter queue or on-failure destination if not processed; can route based on success and failure); stream-based (pushed in batches synchronously from eg Kinesis or DynamoDB with retries N times or M seconds; need to handle batches that have one bad event somehow, preferably from the cloud capability eg BisectBatchOnFunctionError); poller-based (poller pulls synchronously from a queue, probably in batches)"
APRIL NEWSLETTER
MARCH NEWSLETTER
- We list all the latest Java performance related news and articles
- "your primary GC tuning option is now to select the algorithm rather than the old 'tweaking the algorithm' way"
- All the latest Java performance tips extracted in concise form
- "The methodology for analyzing memory leaks is four steps: 1. Do I have a leak (and does it needs fixing - use gc logs to see); 2. What is leaking (instances of which classes - compare two heap histograms separated by enough time to see the leak); 3. What is keeping the objects alive (what instances in the app - you need a heap dump to find these); 4. Where is it leaking from (the code where the objects are created and/or assigned - any memory profiler which can sort on GC generations and provide object creation traces)."
FEBRUARY NEWSLETTER
JANUARY NEWSLETTER
- We list all the latest Java performance related news and articles
- "track your connections and the threads that manage them"
- All the latest Java performance tips extracted in concise form
- "Shuffle sharding: Shard instances (combine them into small groups) to limit the number of instances a particular request source can reach, so that if that request source causes problems (a noisy neighbour), the number of instances impacted is limited (as opposed to full balancing of requests, where the requests could go to any instance, which could potentially impact all instances); Shuffle the shards so that any random shard can contain instances that overlap other shards giving many more shards, if a source request impacts a shard, other source requests going to other shards which include an impacted instance are only partially affected and since there are many more shards you are much less likely to be using the exact same shard as the bad one."
DECEMBER NEWSLETTER
NOVEMBER NEWSLETTER
- We list all the latest Java performance related news and articles
- "with CMS gone you still have 11 other collectors to choose amongst - most likely G1, ZGC, Shenandoah, metronome, gencon+concurrentScavenge or optavgpause"
- All the latest Java performance tips extracted in concise form
- "Service level objectives (SLOs) provide an interface between your application and anyone or application that interacts with it, including: the business agreements for how the application performs; your team members for when it is no longer productive to work on performance; your customers for what they can expect; priority selection amongst competing requirements for the application (breaching your SLOs is the same as any high priority bug that needs fixing)"
OCTOBER NEWSLETTER
SEPTEMBER NEWSLETTER
AUGUST NEWSLETTER
JULY NEWSLETTER
- We list all the latest Java performance related news and articles
- "You should have: 1. A set of metrics that show the business performance of your application (SLIs); 2. A set of targets based on those metrics which show when your application is performing adequately - or not (SLOs); 3. Alerts if the application is not performing adequately and manual intervention is required to get it back on target; 4. Notifications if the application was not performing adequately and automatic intervention got it back on target"
- All the latest Java performance tips extracted in concise form
- "If user CPU utilization averages close to 100% check the garbage collections"
JUNE NEWSLETTER
- We list all the latest Java performance related news and articles
- "The methodology for analyzing memory leaks is four steps: 1. Do I have a leak (and does it needs fixing - use gc logs to see); 2. What is leaking (instances of which classes - compare two heap histograms separated by enough time to see the leak); 3. What is keeping the objects alive (what instances in the app - you need a heap dump to find these); 4. Where is it leaking from (the code where the objects are created and/or assigned - any memory profiler which can sort on GC generations and provide object creation traces)"
- All the latest Java performance tips extracted in concise form
- "A memory profiler which can sort on GC generation counts and also provides object creation traces let's you find where in the code the leaking objects are being created or assigned. A GC generation count is NOT the age of the objects of a class, it is the number of different ages of objects of a class, where the age is the number of GCs the object has survived. So if there are two objects alive of class X, one which has survived 93 GCs and the other 51 GCs, this is a generation count of 2. If there were a third object which had also survived 51 GCs, the generation count would still be 2. Leaking objects will have a high generation count, all other objects (after Full GCs) will have low generation counts"
MAY NEWSLETTER
APRIL NEWSLETTER
- We list all the latest Java performance related news and articles
- "how to tackle all the main performance problems; understanding exactly where the real problems are in concurrency"
- All the latest Java performance tips extracted in concise form
- "For good performance, designs to avoid include: Fine-grained communication; Treating local calls and remote calls equivalently; Designs that are difficult to add caching to; A non-parallelizable workflow; No load balancing in the architecture; Long transactions; Big differences between the data model and object model; Slow extensive embedded security checking; Non intuitive user interfaces; Lack of feedback in the user interface; Locking shared resources for non-short periods; Not paginating data"
MARCH NEWSLETTER
FEBRUARY NEWSLETTER
JANUARY NEWSLETTER
DECEMBER NEWSLETTER
- We list all the latest Java performance related news and articles
- "I continue to highlight the very best of the over 300 tips I've extracted this year. The top tip this month: On modern systems O(N) analysis is insufficient, as memory transfer often dominates algorithm complexity analysis; the next tip ..."
- All the latest Java performance tips extracted in concise form
- "For ultra-low latency: you can't have any GCs; use shared memory; apply single-threaded processing logic (no synchronization) with the thread pinned to the core and all other threads excluded from that core; use simple object pooling (single-threaded); scale by partitioning data across non-shared threads/processes/microservices; spin when waiting for data to keep hold of the CPU and keep it hot; record everything so that you can replay in test to analyse outliers; don't cross NUMA regions, each process/microservice should run on one core; use wait-free data structures (no waits and guaranteed that the thread can always proceed and will finish within a set number of cycles); run replicated hot-hot for high availability"
NOVEMBER NEWSLETTER
- We list all the latest Java performance related news and articles
- "I'll highlight the very best of the over 300 tips I've extracted this year. The top tip of the year was on development techniques that apply to different latency targets ..."
- All the latest Java performance tips extracted in concise form
- "Low location affinity of data is a latency problem. Data that will be used together but are located on different nodes will need to have the data combined to be used and that will cause additional latency. You can't get scale out, low affinity and low latency all at the same time; scaling out will limit affinity, impacting latency."
OCTOBER NEWSLETTER
- We list all the latest Java performance related news and articles
- "Java provides top quality development environments and tools, extensive libraries, a huge and dedicated expert community, a large pool of reasonable priced developers, fabulous performance, massive scalability, excellent multi-core support, and the JVM provides unmatched observability and high reliability. The combination is easily the most reasonable cost maintainable option for you"
- All the latest Java performance tips extracted in concise form
- "Pick the right executor: a fixed size thread pool (sized to the available cores) is appropriate for computationally expensive tasks; a variable sized pool is appropriate for tasks that are short or block a lot; a ForkJoinPool is appropriate for computationally expensive tasks that can be decomposed into subtasks"
SEPTEMBER NEWSLETTER
AUGUST NEWSLETTER
JULY NEWSLETTER
- We list all the latest Java performance related news and articles
- "I wholeheartedly support renaming 'non-functional requirements' to 'quality attributes'"
- All the latest Java performance tips extracted in concise form
- "Response time ranges challenges: seconds - easily achievable (small methods, minimize branching, use cohesion, abstract cleanly); hundreds of milliseconds - needs general performance tactics to achieve (as previous plus: optimized data structures, algorithm complexity minimized, use batching and caching); tens of milliseconds (low latency) - needs specific performance tactics to achieve (as previous plus: memory access patterns optimized for CPU caches, lock free algorithms, asynchronous processing, stateless, RamFS/TmpFS, GC and object lifecycle tuning); under 1 millisecond (ultra-low latency) - very specific techniques needed (as previous plus: thread affinity, NUMA, Large pages, avoid false sharing, data-oriented design, disable c-states, ensure CPU cache friendly operations)."
JUNE NEWSLETTER
- We list all the latest Java performance related news and articles
- "Stateful scaling is much much harder than stateless scaling. Making your application stateless is hitting the scaling jackpot, it becomes just running multiple instances and routing requests. Stateful scaling involves distributed transactions, syncing caches, data routing, ... and much more"
- All the latest Java performance tips extracted in concise form
- "O(N) time complexity analyses tend to assume that: you can ignore constant factors; instructions have the same duration; memory doesn't matter; and instruction execution dominates performance. But on modern systems memory DOES matter and memory access can easily dominate over instruction execution. The processor can execute 300 instructions in the time it takes for data to be retrieved from main memory (RAM)."
MAY NEWSLETTER
APRIL NEWSLETTER
- We list all the latest Java performance related news and articles
- "You need monitoring or you are blind to what is happening in your system. But monitoring only gets you the data, you need to use that data with analyses/thresholds/alerts/consoles/profiles to get full observability"
- All the latest Java performance tips extracted in concise form
- "For load distribution (by a coordinator), choosing the least busy server optimizes performance. But choosing the least busy server has a (coordination) cost, and this is limited by the Universal scalability law. At low parallelism coordination makes latency more predictable, but at high parallelism coordination degrades throughput. A compromise strategy is for the coordinator to choose 2 servers at random and then pick the least busy of the two"
MARCH NEWSLETTER
- We list all the latest Java performance related news and articles
- "We're likely to see cloud infrastructure that hosts containers directly without the underlying VM, giving an extra efficiency to running in a container if you're cloud based - because the container has lower overhead than a cloud virtual machine, so you'll benefit with no real cost!"
- All the latest Java performance tips extracted in concise form
- "A docker image with the full JDK is around 0.5GB. With JDK9+ you can create custom JREs with just the subset of the JDK you need (jdeps tool helps identify which modules an application uses). A minimal JRE containing only the java.base module, eg ' jlink --module-path /docker-java-home/jmods --strip-debug --compress=2 --output java --add-modules java.base' with alpine linux and the musl-libc library in the image results in an image of less than 50MB in size (an order of magnitude smaller). (This is maintained in project Portola)"
Previous newsletters
All our previous newsletters can be viewed from here
How to use this site
This site has four main information resources:
- The uncategorized tips page lists many other web pages with Java performance tuning related information. Each web page has its performance tuning tips extracted and listed immediately after the URL is listed. These tips are being categorized, and the tips page links to those categories currently available. If the performance area you are interested in is not yet categorized, send us an email from this page telling us the categorization you'd like to see. In any of the tips pages, use your browser's "find" or "search" option to identify particular tips you are interested in on the page, and follow up by reading the referenced web page if necessary or desired.
- The resources page lists Java performance tuning resources including books, tools, reports, other performance tuning sites of interest, and Java performance tuning discussion groups.
- The news pages are monthly newsletters listing any new Java performance tuning related information, together with Kirk Pepperdine's discussion group roundup and Javva The Hutt.
- The tool reports pages are detailed introductory
reports on various Java performance related tools, for both free and commercial tools.
This site has been designed to download almost as fast as possible.
(Some stylistic markup and required server-side processing has been used in
preference to absolute speed contraints.)
The web tree contains very few graphics and almost no complex typesetting markup
except for very simple tables, and the main pages can be accessed directly from
the menu.
This line is only to help search engines: Java performance tuning Java tuning Java optimization
Java optimize Java optimizing Java fast Java faster Java speedup Java performance Java High-Performance
|
