The enterprise java application stack is growing bigger and bigger which makes it equally difficult to keep control on all the layers of the infrastructure to get maximum result out of it. One of the basic requirement of any web application is well performing, we will cover here an ideal enterprise java web application setup and see how to analyze and optimize the same using AppDynamics tool.

Take an example of below n-tier java web application interacting with complex middleware system, integrate with numerous external web api’s and equally powerful backend storage system. 

Problem Context

 Looking at above diagram, the application servers are the single communication channel with the webservers and communicate further with internal middleware and backend servers. let’s take example that application servers are not performing well and the web application response is degraded because of some reasons and we will investigate the same further that how to do the performance tuning using some monitoring tooling system. 

Requirements:

Performance tune the application servers to reduce load average (CPU utilization) and improved response time for the web application.

The article covers,

• How to approach the performance tuning
• How to use monitoring tool, AppDynamics, to achieve same
• Figure out bottlenecks in the system
• Take an example of GC tuning 
• Continuous monitoring, happy application

Read the rest of the story, here

Consultant: I hear you have a poor web app response time problem. I can help.

Manager: Thanks. Its a Java/JVM application.

Consultant: Useful information. Lets start with the disk writes chart in a retro startrek theme color to make you feel this is very high tech. In fact next generation if you get me ;-)

Manager: Did I say it is a Java/JVM application.

Consultant: Sure, I get that, so lets look at the CPU on the box. From my vast experience I expect to see the CPU utilization increase as we push more work to that web app thingy. Wow...I'm good.

Manager: That thingy is a Java/JVM application so maybe we should look at the application. We could always start with the very low hang fruit stuff like GC. It might come of a surprise but we actually did not do any investigation of possible options before calling for help.

Consultant: If we really must lets look at GC stuff, though I really would prefer we look at all these other metrics irrespective of what the application is telling us. (I need to fill time and space). GC time does appear to be a significant factor but lets leave that aside for the end of the consulant billing period and look at other stuff such as the database.

Manager: Why? Do you think the database is causing the application to GC?

Consultant: You never know. Stranger things have happen. Best leave it to the experts to decide. Lets not try to be too smart in this early stage and start directing all our investigative work into tunning the GC and finding the code paths which cause the high object allocation rates. Do you have any messaging systems? They cause performance problems too and I have a nice chart for those.

Manager: No. 

Consultant: Not to worry. I assume you have a network?

Manager: Yes. But have we not already covered that with the database analysis?

Consultant: Never mind. I've found the problem. It is all these thread thingies. They are the problem. We need to get rid of them....maybe we need to do some event programming I hear that only needs one thread (in theory) but is stll able to consume all available cores if need be though I heard that is unlikely because eventing is super fast....so fast that it does not even appear to consume processor time...its like memory resident.

Manager: The threads are doing the work that we are sending them. Maybe we should look at streaminling this work which in turn will reduce the number of threads because they will more than likely be available for subsequent in bound requests.

Consultant: Streamlining work? You mean code? Hell not lets just fix your bloody GC settings. I am out of here.

One of the only reasons we post monitoring stories at TSS is to get a rise out of William. I now find myself going out of my way to do it.

William, shoot me an email so we can get that dialog started that we tried to kick-start a while ago.

I knew this was a whole setup...my spider senses did start tingling when I looked over all those irrelevant and meaningless charts.

For a while I was thinking this was a cunning ploy by another vendor, other than AD, setting the sting for a promotion of a heap analysis tool or god forbid a GC log analyser for "real developers that need solid engineering" yes the ones thay shy away from advanced formula one (F1) technology in preference for simple "next generation" stuff that does some simple stuff and looks simply stuffed ;-) Well apparently I was far too generous in thinking so...it was just TSS firing up a signal

Is there one thing in this post that one could not have achieved with stone edge tools like Wily at the beginning of the century? I thought AppDynamics was a modern solution, but I guess it is really just Intrscope with a fresh coat  of paint.

Meant stone age...