Sun Management Center - Sun's Ways of monitoring

"Sun Management Center", a product from Sun Microsystems for monitoring the Spark and x86 hardware running Solaris and Linux. It provides in-depth monitoring and diagnostics of servers and its services. Sun MC is based on server-agent model.

Architecture
Sun Management Center software includes three component layers: console, server, and agent. The product is based on the manager and agent architecture:

Console layer: Console layer is the interface to end users. It exposes web, JWS and console interfaces. Mutiple user can access the same Sun MC at the same time.

Server layer: server is the core, which talks to Console layer and agent layer. It acts as the central repository and stores data(both historical and current). It includes the components such as configuration manager, event manager, topology manager etc., Sun Management 4.0 uses PostgreSQL(open source) db to store data whereas the previous version 3.6 uses Oracle to store data.

Agent layer: Agent layer monitors, gather information about the server/system in which it is deployed and it communicates from server using SNMP(modules are used for gathering monitoring data. Different modules are used for different purposes). Agent apart from monitoring, also has the cabability to manage the nodes. The agent uses rule (it will get from server layer) to raise the alarm if the rule is not met.


Modules: Modules are the components in agent layer responsible for monitoring. They can dynamically loaded, invoked, started, stopped and unisntalled in Sun MC. Kernal reader, file scanning, directory scanning, config reader, fault manager, print spooler, process monitoring are some of the modules.

Like nmon, Sun MC is free to download and use (you can pay and get support). Like Glance for monitoring HP machines, Sun MC can be used to monitor the Sun based systems. Next time when you are planning to do performance testing, tuning on Spack or x86 hardware running Solaris, try Sun MC.

End User Response Time Vs Tool Response Time

In olden days browser is more of display tool and for heavy client side processing, thick clients were used. As time and technology evolved, things have changed and current browser itself is more like think client. As the client side logic becoming heavy, obviously client side processing time has to be added to server side response time to get end user response time.

The Truth about performance testing tool

In modern day internet/web application, response time can be computed as follows

Response time = server side response time + network delay + client side processing time + rendering time

Where as our load testing tools, computes response time as follows.

Response time = server side response time + network delay.

Since client side logic is heavy in modern day web/internet application, most of the tools available today are really missing out the significant portion in response time.

Adding fuel to fire (Java Script Engine)

Because Java Script is so important to the web today, no one can even imagine a web application without java script. A JavaScript engine (also known as JavaScript interpreter or JavaScript implementation) is an interpreter that interprets JavaScript source code and executes the script accordingly in client’s browser. In real, java script execution time by Java Script Engine is also added to end user response time. To name few Spider monkey, V8 are couple of open source java script engine.

Even if some tools has ability (like Loadrunner click & script), it is very limited to a particular browser and particular java script engine.

More Fuel

Even if a tool is able to makeup the java script's response time, calculating full response time by tool has exception. PLUGINS. It is practically impossible for a tool vendor to work with all plugins available. Java and flash are the commonly used plugins in lot of web sites.

Just want to quote an example

In one of my previous client environment, single user test for a particular page click takes around 50 sec, whereas the loadrunner @ 1000 user load reported the max response time as 10 sec. After seeing the result, client has called in for a meeting and they demonstrated his portion and proved that in real, that particular page takes much longer time to view. To stick to our result, we have done a sniffing of that request using network sniffer and showed that client side JS doing some nasty calculation is the culprit not the server. Also we explained them that, whatever loadrunner gives are the server side response time not the end user response time.

So sad

Even if performance testing tool vendors wants to include client side response time, it is very difficult for them as whole lot of java script engine out in market with various market shares.

Even tough for some, it is hard to believe that server side response time and end user response time are very different, we have to accept(as it is fact).

AIX vs FreeBSD vs HP-UX vs RedHat vs Solaris vs Tru64

Working in lot of flavours of Unix/Linux? Not able to remember all the commands? 

Then here is the help for you:

http://www.unixguide.net/unixguide.shtml

Cheers,

Thiru

Glance - HP Way of optimizing the system's performance

I have found a webcast which explains how to use HP glance for monitoring and tuning HP Unix systems. Click here for more information. 

Few things to notice

1. We need to buy license from HP (or you can use 60 day trial version)

2. It even supports monitoring AIX, Linux, Solaris apart from HP Unix.

3. Supports drill down to find out what is going on system

To me Glance looks like more powerful nmon. For those of you who are sick of monitoring systems using vmstat, sar, iostat etc  glance (and nmon) are good tools.

Cheers,

Thiru

Be proud of being developer

Click the image to enlarge

Executing command on remote host, remote monitoring unix/Linux flavour

I was given some exercise on remote monitoring. Here is how I cracked the same. I have splited the task into 2 parts. 1) Executing a command on remote host 2) Run vmstat in remote host and collect performance statistics.

Steps for Executing the command on remote host

1. Create/update .netrc file in user home directory and add credentials of all the machines that we need to be accessed remotely. Format should be as follows: machine  login  password 
2. Execute “chmod 600 .netrc” so that only owner will have read/write access.
3. To execute the command on remote host use the following command:rexec   

Few examples for remote monitoring

HP Unix:

rexec remote_hp_ux_host vmstat 1 2 | tail -1 | awk '{print "Load Average : "$1"\nFree Mem :"$5"\nUser CPU : "$16"\nSystem CPU : "$17"\nIdle : "$18}'

 

AIX:

Rexec remote_aix_host vmstat 1 2 | awk -v  psize="`pagesize`" '{if (NR ==2) print "Total "$4"\nPage Size : " psize}{if (NR == 8) print "Free list sz: "$4"\nUser CPU   : "$14"\nSystem CPU : "$15"\nIdle       : "$16"\nIO Wait    : "$17}'

Rest of Flavours:

Give a try and send me a feed back.

Remote monitoring Linux/unix servers from linux/unix server

Steps for Executing the command on remote host

1. Create/update .netrc file in user home directory and add credentials of all the machines that we need to be accessed remotely. Format should be as follows

machine login password

 

2. Execute “chmod 600 .netrc” so that only owner will have read/write access.
3. To execute the command on remote host use the following command

rexec

To remote monitor

rexec remotehost vmstat 1 10