Today we released a new adaptive control valve metering extension, jvalve, that self regulates the execution of probes (methods) associated with an adaptive control valve in the event of an observed runtime performance jitter. Surprisingly this type of adaptive control handles jitter by introducing delay (thread suspension), which to a client can appear as jitter though deliberate and controlled. In doing so the adaptive control valve minimizes the chance of uncontrolled jitter continuing to plague the processing performance within a metered server runtime. The most common causes of performance jitter are excessive garbage collection, as a result of high allocation rates, and high concurrent work processing, so in general any form of temporary suspension of processing, until jitter is dissipated, can help speed up the resumption to normal processing performance levels.
You might ask how different is this from the typical stop-the-world garbage collection events within an application runtime when all application threads are suspended? Why not allow garbage collection to “naturally” throttle the processing? For one thing improved performance, which we already demonstrated in Adaptively Controlling Apache Cassandra Client Request Processing. What the jvalve metering extension brings additionally to the table is the ability to be selective in which threads are suspended, by way of pending invocation targets, during the early warning signs of possible performance incident. Valves allow us to temporarily suspend any further invocation of particular methods (and their call paths). For each valve we can associate one or more probes (methods) and set the sensitivity of the valve to jitter, via the interval, sleep, tolerance and run control set points, offering a kind of ordering (reverse preference) to the suspension of thread processing. By making method x, and its associated valve, more sensitive than method y, and its associated valve, those threads calling into method x will more than likely experience controlled delay before those threads calling into method y. In fact what we would like to see happen is the throttling of method x alleviates further performance jitter eliminating the need to suspend threads calling into method y.