Java Performance Tuning

Java(TM) - see bottom of page

|home |services |training |newsletter |tuning tips |tool reports |articles |resources |about us |site map |contact us |
Tools: | GC log analysers| Multi-tenancy tools| Books| SizeOf| Thread analysers|

Our valued sponsors who help make this site possible
JProfiler: Get rid of your performance problems and memory leaks! 

News March 2016

JProfiler
Get rid of your performance problems and memory leaks!


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:



JProfiler
Get rid of your performance problems and memory leaks!


Back to newsletter 184 contents

There are situations when making an operation as fast as possible is the wrong thing to do. I'm not talking about estimation here, I'm talking about situations where you deliberately want to slow down what you are doing.

In the performance world throttling is a well known example: you need to slow down requests processing upstream (typically by queueing somewhere) in order to avoid overwhelming a downstream resource that doesn't have throttling protection (see for example our linked article by Paul Cook in this month's articles which describes exactly this).

A note from this newsletter's sponsor

New Relic - Try New Relic today and get your free Data Nerd shirt!
Free SaaS APM tool to monitor, troubleshoot, and tune apps
running on Websphere, Weblogic, Tomcat, Jetty, JBoss, Solr, Resin

Similarly, when exclusively obtaining a shared resource, sometimes you need to backoff and wait a bit, otherwise too many threads try to acquire the resource and they thrash, resulting in reduced overall throughput.

I recently came across a different type of example, string equality, which has two competing requirements. In the performance world, we always go for the 'fail fast' implementation - as with any collection comparison, you compare subsets of the collection, and fail as soon as you know any subset does not equate. But there is a competing requirement here, for security. Many otherwise secure implementations are vulnerable to a timing attack - finding which inputs take longer to respond to often gives significant clues to breaking security. The most simple example is if you are comparing a (even encrypted) password string character by character - with fail fast, the more characters that are correct in sequence, the longer the comparison takes to return; consequently instead of making guesses rely on all the characters, you can attack each character in order, making it easy to crack.

Security requires the time taken to check for equality to be independent of the equality of the strings. This is why java.security.MessageDigest.isEqual uses a constant-time equality check which is the type you should be using instead of the fail-fast java.lang.String.equals() implementation if you are checking encrypted strings (though note in this case the size of the strings still fails fast; it is appropriate for message digests as these compare known length byte arrays, but would not be appropriate for the generic comparison case).

Now on to our usual links to tools, articles, news, talks and as ever, all the extracted tips from all of this month's referenced articles.

A note from this newsletter's sponsor

Developers wanted in London - We're working on IoT, big data, highly
concurrent high througput 24/7/365 systems, some real-time, needing
total fault tolerance and global distribution. Apply now!

News

Java performance tuning related news.

Tools

Java performance tuning related tools.

A note from this newsletter's sponsor

Site24x7.com : Deep dive Application Performance Monitoring
Fix performance issues with Java, .NET and Ruby platforms
Monitor app instance at $12/Month. 30-day free trial. Sign Up!

Articles

Jack Shirazi


Back to newsletter 184 contents


Last Updated: 2017-10-01
Copyright © 2000-2017 Fasterj.com. All Rights Reserved.
All trademarks and registered trademarks appearing on JavaPerformanceTuning.com are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. JavaPerformanceTuning.com is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
URL: http://www.JavaPerformanceTuning.com/news/news184.shtml
RSS Feed: http://www.JavaPerformanceTuning.com/newsletters.rss
Trouble with this page? Please contact us