JProfiler Get rid of your performance problems and memory leaks! Modern Garbage Collection Tuning 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: Training online Threading Essentials course JProfiler Get rid of your performance problems and memory leaks!

Back to newsletter 033 contents | All Javva's articles

The Orgasmatron

When a colleague pointed me to this story about turning phones into sex toys, I couldn't decide whether it was a joke. But then I realized that it was technically feasible, and in fact quite easy to implement, so consequently whether this particular story was a joke or not didn't matter. Sooner or later it would be an available product. There's progress for you. It's only a matter of time before we have the orgasmatron (check Woody Allen's "Sleeper" to find the technical specs for that gadget).

Diary of a Hutt

June 4. Server needs a seeing to. We have monitors in in place to give us early warning signs, and our weekly trend analysis indicates that we may soon start breaching response times. Seems to be down to increased workload.

June 11. Publicity time. I need to make sure that we get maximum exposure for our efforts. It always helps for lots of people to see you doing good things. Caught Parsons at lunch and starting being expansive about our fabulous monitoring setup. Naturally he wanted to see it. So I got Boris to go through all the logs with the graphics. Gotta have graphics if you want to show something to the executive level. Without graphics, it seems like you don't actually have data for some people. Parsons set up a meet with some of the other Big D's to repeat the display. Boris was loving the attention. I was delighted to be getting the exposure. Parsons was pushing the proactive nature of his department. He'd obviously done his sums, because he gave the other Big D's a detailed breakdown of exactly what the downtime would have cost if we hadn't been monitoring the system and the workload had become too heavy to handle. Afterwards he came round to me with a worried look on his face: "You will be able to maintain performance without breaching the thresholds, won't you?". Yes of course we will you silly suit. Why would I be broadcasting this otherwise?

June 18. Showed Boris and Brainshrii the monitoring framework. More to the point, showed them the "slack" in the monitor that meant we didn't have much to do to maintain performance. Boris grunted his usual noncommital grunt, but I could see he was impressed. Brainshrii went away looking thoughtful.

June 25. Brainshrii hooked up the monitor to the log analyser and adjusted the monitor delay code to automatically adjust the performance according to the workload and current response times, flattening out the response time curve. He also added a threshold to the delay so that we get warned if it goes too low. This means that the server now has auto-regulated performance. Response times should appear to be completely flat no matter the workload for the forseeable future. Wish I'd thought of that, so nice. Of course we can't detail the mechanism to anyone, I imagine someone or other would go ballistic. But how many complex client/server systems do you know of that have completely predictable and deterministic response times under all workloads?

BCNU

Javva The Hutt.

Back to newsletter 033 contents