Mon Sep 12 16:10:46 GMT 2016
*Do not use locks in the main transaction flow because they cause context switches, and therefore latency and unpredictable jitter.
*Never have more threads that need to run than you have cores available.
*Set affinity of threads to cores, or at least sockets, to avoid cache pollution by avoiding migration. This is particularly important when on a server class machine having multiple sockets because of the NUMA effect.
*Ensure uncontested access to any resource respecting the Single Writer Principle so that the likes of biased locking can be your friend.
*Keep call stacks reasonably small. Still more work to do here. If you are crazy enough to use Spring, then check out your call stacks to see what I mean! The garbage collector has to walk them finding reachable objects.
*Do not use finalizers.
*Keep garbage generation to modest levels. This applies to most JVMs but is likely not an issue for Zing.
*Ensure no disk IO on the main flow.
*Do a proper warm-up before beginning to measure.
*Do all the appropriate OS tunings for low-latency systems that are way beyond this blog. For example turn off C-States power management in the BIOS and watch out for RHEL 6 as it turns it back on without telling you!
*Macro-benchmarking is much more valuable than micro-benchmarking.
*Amazing results are achieved by truly agile companies, staffed by talented individuals, who are empowered to make things happen. Make sh*t happen is more important than following a process.
How to monitor - https://plumbr.eu[..]siness-value-from-performance-monitoring
How to measure latency - https://vanilla-java.github.io[..]/07/20/Latency-for-a-set-Throughput.html
Various cause of latency, and the solution - https://www.informatica.com[..]Topics-in-High-Performance-Messaging.htm
(google search) (amazon search)