About Java Sanity
About this site:
Java Sanity is a site dedicated to the J2EE Application Server administrator.
This site's primary focus is on managing, tuning and deploying J2EE Application Servers in a production environment. Some topics that I expect to cover are: tuning memory, analyzing Java thread dumps, troubleshooting core dumps and much more. General Java and Programming topics may also be covered from time to time, thought that is not the main focus.
About the site slogan: Tune the problem not the symptom
In my years as a J2EE Application Server administrator, I've seen plenty of times where the response to a problem is to "fix the symptom" and it never works out very well.
A common scenario: Many J2EE application servers have a fixed thread pool size with a queue that starts filling up once all threads are in use. I frequently see the response to running out of threads (and filling up the queue) as just "adding more threads" without any analysis into the root cause of the problem. Running out of threads is usually a symptom, not the root cause. Realize that when throughput for your application server is less than the rate traffic comes in, you will start queuing up. The solution is to identify the bottleneck and solve it. Just reacting to the situation by adding more threads may actually make matters worse. If you haven't fixed the bottleneck, you will very likely hit that bottleneck even harder. And you may derail your troubleshooting efforts by introducing additional symptoms that draw you away from the root cause.
In one example, an application team added more threads to their application server and things got worse. The average response time got higher and the increased number of threads were more threads doing work which greatly increased their memory footprint. Then they started running out of memory and decided the solution was to increase the heap. They didn't actually solve the problem until they asked the right question: What are the threads doing and why am I running out of them? They solved the problem was tuning their SQL queries and properly indexing tables in the database.
While there is certainly a scenario where increasing threads can help, it may not be as often as you think. Another slogan I like is: Tune for throughput not concurrency. Your need for concurrency increases as the time it takes to serve your requests goes up. You will reach a point where you either cannot add more concurrency or it gets very expensive to do so (e.g. you have to throw hardware and software licenses at the problem)
About me:
I have a Bachelors Degree in Computer Science from the University of Kansas, the focus was software design and development. My professional focus started with Unix & Network administration with a short period of time doing Database administration. Starting in 1999, my focus shifted to architecture and support of Web software and related products. During this time, I've learned a lot about configuring, tuning and troubleshooting large scale production environments built on the J2EE Model.
Some of the web and J2EE related products I've supported are:
WebLogic Application Server 4.5.1, 5.x, 6.x, 7.x, 8.x, 9.x, 10.x
WebSphere Application Server 5.x, 6.x
Tomcat 4.x, 5.x
Apache Web Server 1.3, 2.0, 2.2
IBM HTTP Server 1.3, 2.0
Netscape Enterprise/iPlanet/SunONE/Sun Java Systems Web Server 3.x, 4.x, 6.x (The same product by many names)