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 |

Our valued sponsors who help make this site possible
AppDynamics: Get complete browser to backend visibility. Monitor Now! 

New Relic: Try free w/ production profiling and get a free shirt! 

ManageEngine's Site24x7: End-to-End analysis on Java EE web transactions. Sign up for FREE! 

Javva The Hutt August 2003

JProfiler
Get rid of your performance problems and memory leaks!

Chart Java Jitter with jHiccup
Monitor and identify pauses in your Java apps. Download now

Why is my application so slow?
Learn 3 ways to detect Java Application Performance Trends


Java Performance Training Courses
COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs

See Your Message Here
You could have your tool advertised here, to be seen by thousands of potential customers

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:


AppDynamics
AppDynamics: Get complete browser to backend visibility. Monitor Now!

New Relic
New Relic: Try free w/ production profiling and get a free shirt!

ManageEngine
ManageEngine's Site24x7: End-to-End analysis on Java EE web transactions. Sign up for FREE!


JProfiler
Get rid of your performance problems and memory leaks!

Chart Java Jitter with jHiccup
Monitor and identify pauses in your Java apps. Download now

Why is my application so slow?
Learn 3 ways to detect Java Application Performance Trends


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


Last Updated: 2014-09-29
Copyright © 2000-2014 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/javvathehutt033.shtml
RSS Feed: http://www.JavaPerformanceTuning.com/newsletters.rss
Trouble with this page? Please contact us