|
|
|
|
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).
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.
Java performance tuning related news.
Java performance tuning related tools.
Back to newsletter 184 contents
