Tuning transport channel services

Tuning transport channel services


The transport channel service manage client connections and I/O processing for HTTP and JMS requests. These services provide a highly scalable foundation to WebSphere Application Server request processing. Java NIO based architecture has limitations in terms of performance, scalability and end user usability. Therefore, integration of true asynchronous I/O is implemented. This implementation provides significant benefits in usability, reduces the complexity of I/O processing and reduces that amount of performance tuning you have to perform.Changing the default values for settings on one or more of the transport channels associated with a transport chain can improve the performance of that chain.

I copied this diagram from IBM Redbook, it explains how the Transport channel service works.

You can access the the transportation related configuration in WAS Admin Console by going to Servers - server_name -> Web Container settings - Web Container transport chains, then select WCInboundDefault, which is the virtual host for handling all the requests to web application on that server.

As you can see there is a hyper link for configuring settings related to each of the three channels

#############################################################################

Web server support

Web server support


WebSphere Application Server provides Web server plug-ins that work with a Web server to route requests for dynamic content, such as servlets, from the Web server to the proper application server. A Web server plug-in is specific to the type of Web server. It is installed on the Web server machine and configured in the Web server configuration.

A plug-in configuration file generated on the application server and placed on the Web server is used for routing information. In order to manage the generation and propagation of these plug-in configuration files, Web servers are defined to the WebSphere Application Server configuration repository. In some cases, Web server configuration and management features are also available from the WebSphere administrative tools.

The following are the supported Web servers for WebSphere Application Server

V6.1:
•Apache HTTP Server

•Domino Web Server

•IBM HTTP Server

•Microsoft Internet Information Services

• Sun Java System Web Server (formerly Sun ONE and iPlanet)

Request routing using plug-in

Request routing using plug-in


The Web Server plug-in uses an XML configuration file to determine whether a request is for the Web Server of the application server

. When a request reaches the Web Server, the URL is compared to those managed by the plug-in. IF a match is found, the plug-in configuration file contains the information needed to forward the request to the web container using the web container inbound chain.

For example lets say you make a request to http://localhost/sessionaffinity/SessionAffinityServlet URL, so the Web Server Plugin will check the /sessionaffinity URL to find out how it is should be handled, It will check if there is matching UriGroup element in plugin-cfg.xml

<UriGroup Name="default_host_cluster1_URIs">

<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/HelloWorldWeb/*"/>

<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/NameSpaceWeb/*"/>

<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/dynasession/*"/>

<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/webappext/*"/>

<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/dynacachereplication/*"/>

<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/helloworldportlet/HelloWorldPortlet/*"/>

<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/helloworldportlet/HelloWorldPortlet2/*"/>

<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/helloworldportlet/*"/>

<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/cachemonitor/*"/>

<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/sessionaffinity/*"/>

</UriGroup>


In this case it knows that the /sessionaffinity/* URL is for dynamic content, so the next part is how to route it to correct server. It will read value of Name attribute for the UriGroup which is default_host_cluster1_URIs, and name of the cluster is cluster1. It will use these values find out virtual host and cluster

<Route ServerCluster="cluster1" UriGroup="default_host_cluster1_URIs" VirtualHostGroup="default_host"/>

<VirtualHostGroup Name="default_host">

<VirtualHost Name="*:9080"/>

<VirtualHost Name="*:80"/>

<VirtualHost Name="*:9443"/>

<VirtualHost Name="*:5060"/>

<VirtualHost Name="*:5061"/>

<VirtualHost Name="*:443"/>

<VirtualHost Name="*:9081"/>

<VirtualHost Name="*:9082"/>

</VirtualHostGroup>

<ServerCluster CloneSeparatorChange="false" GetDWLMTable="false" IgnoreAffinityRequests="true" LoadBalance="Round Robin" Name="cluster1" PostBufferSize="64" PostSizeLimit="-1" RemoveSpecialHeaders="true" RetryInterval="60">

<Server CloneID="14dtuu8g3" ConnectTimeout="0" ExtendedHandshake="false" LoadBalanceWeight="2" MaxConnections="-1" Name="dmgrNode01_server2" ServerIOTimeout="0" WaitForContinue="false">

<Transport Hostname="dmgr.webspherenotes.com" Port="9081" Protocol="http"/>

<Transport Hostname="dmgr.webspherenotes.com" Port="9444" Protocol="https">

<Property Name="keyring" Value="C:\Cert\HTTPServer\Plugins\config\webserver2\plugin-key.kdb"/>

<Property Name="stashfile" Value="C:\Cert\HTTPServer\Plugins\config\webserver2\plugin-key.sth"/>

</Transport>

</Server>

<Server CloneID="14dtuueci" ConnectTimeout="0" ExtendedHandshake="false" LoadBalanceWeight="2" MaxConnections="-1" Name="dmgrNode01_server4" ServerIOTimeout="0" WaitForContinue="false">

<Transport Hostname="dmgr.webspherenotes.com" Port="9082" Protocol="http"/>

<Transport Hostname="dmgr.webspherenotes.com" Port="9445" Protocol="https">

<Property Name="keyring" Value="C:\Cert\HTTPServer\Plugins\config\webserver2\plugin-key.kdb"/>

<Property Name="stashfile" Value="C:\Cert\HTTPServer\Plugins\config\webserver2\plugin-key.sth"/>

</Transport>

</Server>

<PrimaryServers>

<Server Name="dmgrNode01_server2"/>

<Server Name="dmgrNode01_server4"/>

</PrimaryServers>

</ServerCluster>

It knows that the cluster1 has two servers dmgrNode01_server2 and dmgrNode01_server4 and from the cluster definition it can find out the http and https port and then forward request to either of the server. The cluster definition also says that the Load balancing

algorithm is Round robin

#####################################################################

Unmanaged and managed web server

Unmanaged web server


Unmanaed web servers reside on a System without a node agent. This is the only option in a standalone server environment and is a common option for Web Servers installed outside a firewall. The use of this topology requires that each time the plug-in configuration file is generated, it is copied from the machine where WebSphere Application Server is installed to machine where the server is running.

If the Web server is defined to an unmanaged node, you can do the following:

1.Check the status of the Web server.

2.Generate a plug-in configuration file for that Web server.

3.If the Web server is an IBM HTTP Server and the IHS Administration server is

installed and properly configured, you can also:

◦Display the IBM HTTP Server Error log (error.log) and Access log (access.log) files.

◦Start and stop the server.

◦Display and edit the IBM HTTP Server configuration file (httpd.conf).

◦Propagate the plug-in configuration file after it is generated.

You cannot propagate an updated plug-in configuration file to a non-IHS Web server that is defined to an unmanaged node. You must install an updated plug-in configuration file manually to a Web server that is defined to an unmanaged node
 
Managed web server


In a distributed server environment, you can define multiple Web servers. These

Web servers can be defined on managed or unmanaged nodes. A managed node

has a node agent. If the Web server is defined to a managed node, you can do

the following:

1.Check the status of the Web server.
2.Generate a plug-in configuration file for that Web server.
3.Propagate the plug-in configuration file after it is generated.
4.If the Web server is an IBM HTTP Server (IHS) and the IHS Administration

server is installed and properly configured, you can also:

◦Display the IBM HTTP Server Error log (error.log) and Access log

(access.log) files.

◦Start and stop the server.

◦Display and edit the IBM HTTP Server configuration file (httpd.conf)
 
################################################################################

Remote Web server on an unmanaged node

Remote Web server on an unmanaged node

The deployment manager and the Web server are on separate machines. The script that defines the Web server is run against the deployment manager and you will see an unmanaged node created for the Web server node. In this case there wont be a node agent on the web server machine


Assuming that the Deployment manager is already installed on Machine B follow these steps

1.Install the Web server on machine B.

2.Install the Web server plug-in on machine B by performing the following

steps:

◦Select Remote installation.

◦Enter a name for the Web server definition. The default is webserver1.

◦Select the location for the plug-in configuration file. By default, the file will be placed in the directory that contains the server's configuration. For example, when the name specified for the Web server definition in the previous step is webserver1, the default location for the plug-in file is:

/config/webserver1/plugin-cfg.xml

During the installation, the following tasks are performed:

◦A temporary plug-in configuration file is created and placed in the location specified.


◦The Web server configuration file is updated with the plug-in configuration, including the location of the plug-in configuration file.

◦A script is generated to define the Web server and an unmanaged node to

WebSphere Application Server. The script is located in: /bin/configure

3.At the end of the plug-in installation, you need to copy the script to the

/bin directory of the deployment manager machine (machine A),

start the deployment manager, and execute the script.

When the Web server is defined to WebSphere Application Server, the plug-in configuration file is generated automatically. For IBM HTTP Server, the new plug-in file is propagated to the Web server automatically. For other Web server types, you need to propagate the new plug-in configuration file to the Web server.

What is work load management

What is work load management


Workload management is the concept of sharing requests across multiple instances of a resource. Workload management techniques are implemented expressly for providing scalability and availability within a system. These techniques allow the system to serve more concurrent requests. Workload management allows for better use of resources by distributing load more evenly.

Components that are overworked, and therefore, perhaps a potential bottleneck, can be routed around with workload management algorithms. Workload management techniques also provide higher resiliency by routing requests around failed components to duplicate copies of that resource.

In WebSphere Application Server, workload management is achieved by sharing requests across one or more application servers, each running a copy of the Web application. In more complex topologies, workload management is embedded in load balancing technologies that can be used in front of Web servers.

Workload management (WLM) is a WebSphere facility to provide load balancing and affinity between nodes in a WebSphere clustered environment. WLM can be an important facet of performance. WebSphere uses WLM to send requests to alternate members of the cluster if the current member is too busy to process the request in a timely fashion. WebSphere will route concurrent requests from a user to the same application server to maintain session state.
 
Work load management and clustering


Clustering application servers that host Web containers automatically enables plug-in workload management for the application servers and the servlets they host. Routing of servlet requests occurs between the Web server plug-in and the clustered

application servers using HTTP or HTTPS

This routing is based on weights associated with the cluster members. If all cluster members have identical weights, the plug-in sends equal requests to all members of the cluster, assuming no strong affinity configurations. If the weights are scaled in the range from 0 to 20, the plug-in routes requests to those cluster members with the higher weight value more often. No requests are sent to cluster members with a weight of 0 unless no other servers are available.


Weights can be changed dynamically during runtime by the administrator. A guideline formula for determining routing preference is:

% routed to Server1 = weight1 / (weight1+weight2+...+weightn)

Where there are n cluster members in the cluster.

The Web server plug-in temporarily routes around unavailable cluster members
 
#################################################################################

Work load management for EJB

Work load management for EJB


Workload management for EJB containers can be performed by configuring the Web container and EJB containers on separate application servers

. Multiple application servers with the EJB containers can be clustered, enabling the distribution of EJB requests between the EJB containers

In this configuration, EJB client requests are routed to available EJB containers in a round-robin fashion based on assigned server weights. The EJB clients can be servlets operating within a Web container, stand-alone Java programs using RMI/IIOP, or other EJBs.

The server-weighted, round-robin routing policy ensures a distribution based on the set of server weights that have been assigned to the members of a cluster. For example, if all servers in the cluster have the same weight, the expected distribution for the cluster is that all servers receive the same number of requests. If the weights for the servers are not equal, the distribution mechanism sends more requests to the higher weight value servers than the lower weight value servers. The policy ensures the desired distribution based on the weights assigned to the cluster members.

You can also choose to have requests sent to the node on which the client resides as the preferred routing. In this case, only cluster members on that node are chosen (using the round-robin weight method). Cluster members on remote nodes are chosen only if a local server is not available.

When planning for clustering, determine the number of application servers and

their physical location. Determine the server weights to assign for application servers based on considerations such as system stability and speed. When creating the cluster, consider using the prefer local setting to ensure that when a client (for example, a servlet) calls an EJB, WLM will attempt to select the EJB on the same system as the client, eliminating network communication.

Creating web werver definition in WAS Admin console

Creating web werver definition in WAS Admin console

During the installation of the plug-in, the Plug-ins installation wizard creates a Web server configuration script named configure. This configuration script is used to create the Web server definition and, if necessary, the node definition in the configuration of the application server.


Each stand-alone application server can have only one Web server definition. A distributed server environment, on the other hand, can have multiple Web server definitions. The script creates a new Web server definition unless the Web server name is the same.

The Plug-ins installation wizard stores the script in the /bin

directory on the Web server machine. If the plug-in is installed locally (on the same machine as the application server), the configuration script will be run automatically. For remote installations, you must copy the script from the Web server machine to the /bin directory on the application server machine for execution. The script runs against the default profile. If one machine is running under Linux or UNIX and the other machine is running under Windows, use the

script created in the /bin/crossPlatformScripts directory.

I tried this in my local environment, after installing plug-in i copied the configurewebserve1.bat from plug-in _home/bin directory and to the DMGR_HOME/bin directory and executed it. It took few minutes to execute and i could see this output

After that i logged into the WAS Admin Console and went to Servers - Web Servers, i could see webserver1 being added in there

When i clicked on the webserver1 i could see the details on the webserver1, such as location of web server installation, location of httpd.conf file,

If i click on the Plug-in properties link on the web server definition i can see the plugin related details, such as location of plugin installation, location of plugin-cfg.xml,..

 

#############################################################################