|
|
|
|
Back to newsletter 161 contents
Performance targets are advocated by almost everyone. If you want to performance tune effectively, you should have targets in place, otherwise you can tune the wrong thing, and waste effort and resources tuning too much.
But there are plenty of times when you DO tune without a target. I suspect that the majority of tuning effort (that's tuning effort, not effective tuning!) is done at development time, developers looking at some of their code and thinking "I can make this a little faster by doing that", despite having no idea whether that piece of code will ever need to be a little faster. This is the amorphous, and probably wasteful tuning target of "make it as fast as I can". Are there times when this is a reasonable target? Not really. But ...
But the tuning target isn't really "make it as fast as I can". It's actually "make it as fast as I can within a reasonable effort". Now while that's not an ideal performance target, it is a valid one. A performance target has several components:
So the answers for a page download might be 1 - "page X downloading"; 2 - "1 second for 9999/10000 downloads"; 3 - "A load testing tool, time elapsed from request initiation in the client until download is complete"; 4 - Actually, this is a really hard question to answer.
Realistically, you'd expect a page download "too slow" problem to be fixed in a few days. But maybe this is a critical page and 1 second is already at the limit of testing acceptability. What if the page is taking 100 seconds and the project can't go live without a 1 second target. What if the entire architecture needs rewriting to achieve acceptable time? More often than not, the answer to this question is "find out the current timing, see how far that is from unnacceptable, estimate how much it will take to fix it, and ask the funder whether they want to spend that much".
Of course, the developer's answers to those questions on their code during development are often 1 - "this code"; 2 - "this code"; 3 - "my experience of what I think is too slow by reading the code"; 4 - "a few hours". Whether you think that's reasonable or not probably doesn't matter, it's a fact of life that developers will intermittently answer this way on the code they're working on. Now on to our links to Java performance tools, news, articles 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 161 contents
