WSADMIN - Part 1

The wsadmin program is a scripting engine for performing administrative tasks on an application server or its configuration. It can execute individual commands as well as in interactive fashion , or it can execute script file.

The way wsadmin program is executed is dependent on the Operating system being used. The examples below shows how wsadmin program is executed in Windows and Unix environment.The ./ before the name of the file to be executed on a Unix environment is an indication that the specified file is located in the current directory.

• AIX —wsadmin.sh
• Linux —wsadmin.sh
• z/OS —wsadmin.sh
• Windows —wsadmin

are options specified by user and are optional.


Where is wsadmin located :-
  
In case of standalone application server, wsadmin is located at WAS_HOME /bin directory.


In ND application server,  wsadmin.sh is located both at WAS_HOME/bin  and also at WAS_PROFILE_HOME/bin

WAS_HOME is location where base binaries are installed .
WAS_PROFILE_HOME is location where profile is created.

Launching of wsadmin :-

Here I will be explaining and showing launching of wsadmin in ND environment on Unix Operating System.Basically in ND environment, best practice is to launch wsadmin from Deployment profile.We can launch wsadmin from /bin or from Node profile also, but it is almost always launched from Deployment profile only.

 The way we launch wsadmin also depends upon whether Websphere have security turned on or not.
  1. If Global security is not turned on, it is launched just by executing ./wsadmin.sh command as shown below in screenshot.
 



 2. If Global security is turned on, then we will have to pass user name and password to connect to wsadmin program and options we need to pass is described below and shown below in screenshot.
               ./wsadmin.sh -user -password



3. If Global security is turned on and we don't want to pass user and password every time we execute wsadmin.So, for that , we need to update 3 properties in soap.client.props located at /properties, below are the properties which we need to update.

1. Update "com.ibm.SOAP.securityEnabled" to  value as true.
2. Update "com.ibm.SOAP.loginUserid" with websphere admin user.
3. Update "com.ibm.SOAP.loginPassword" with websphere admin password.

You don't have to bounce Deployment manager to have this take affect,you can do this on the fly , whether you want to enable this functionality or disable this functionality after enabling.

Below screenshot shows the location of soap.client.props


Below it shows the properties with updated values


Below screenshot shows, after updating this we don't have to pass user name and password with we are executing wsadmin , with global security on in websphere.


This concludes the first part of wsadmin,Second part to follow soon. Keep yours eyes open and check the blog with  other updates also. Please comment and let me know where do I need to improve when I am explaining as I want to explain everything in as easy way as it can be and if you like this port it then please share it on facebook or twitter.

Measuring Repsonse time of IBM HTTP Webserver

Response times can be found in the access log file identified by either the TransferLog or CustomLog directives defined in the IBM HTTP Server's httpd.conf file as long as the LogFormat directive is modified to include either the %D or %T format parameters. In addition to these two parameters, the LogFormat should be updated with a constant string (e.g. TIME:) that can be used to easily identify the response times in the access log. The %D parameter will report the time taken to serve the request, in microseconds, while the %T will report the time taken to serve the request in seconds.
The following example shows how to modify the default common LogFormat found in the httpd.conf file to report the time in microseconds.
Original definition:
LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog logs/access.log common

Which will produce output similar to the following:

127.0.0.1 - - [04/Nov/2011:21:06:05 -0400] "GET / HTTP/1.1" 200 3325


Change to:
LogFormat "%h %l %u %t \"%r\" %>s TIME: %D %b" common
CustomLog logs/access.log common

Example output found in the access.log will look like the following:

127.0.0.1 - - [04/Nov/2011:21:06:05 -0400] "GET / HTTP/1.1" 200 TIME: 78125 3325

The text in bold blue shows the response time in microseconds.

With this information, you can now parse the access log looking for requests that meet specific response time criteria.