
Find long-running IHS (web) requestsQuick way to locate or watch for long-running IHS requests:
Logging response times
Enab LogFormat "%h %l %u %t \"%r\" %>s %b %D" common
Finding Responses longer than 1 secondThen, if you put it at the end of the line like that, the following egrep pattern could filter out, say, those items that take longer than 1 second: egrep "[0-9]{7}$" access_log Where 7 digits means you've gotten past 999,999 microseconds. If you don't want it at the end of the line, you could add some fixed delimiters to locate it in the log string in another manner.
Actively watching for long-running responsesOr to actively watch for such requests (assuming you have command-line tail on your platform): tail -f access_log | egrep "[0-9]{7}$"
Tags:  httpd apache tuning ihs logging grep |
||||||||||||||||||
mod_mpmstats to analyze thread usage in IBM HTTP Server
(Related to my earlier post
Found this useful tidbit today from IBM
This is a quick way to look at your IHS load over time.
Tags:  httpd apache mpmstats stats ihs |
||||||||||||||||||
Using IBM HTTP Server 6.1 diagnostic capabilities with WebSphere
Using IBM HTTP Server 6.1 and later diagnostic capabilities with WebSphere
This could be useful. Apache mod_status is available in IHS, and when it's enabled it provides information about the individual threads running under the httpd processes. The information is provided as a simple web page via a URL (that of course can be protected by any of the various Apache mechanisms). With the default httpd.conf file, only the following changes are required:
Tags:  httpd plugin apache debugging mod_status diagnostic websphere ihs |
||||||||||||||||||
Temporarily Disabling WebSphere Cluster MembersBackgroundIt seems that in our current configuration the WebSphere plugin does not reliably stop sending requests to a Cluster member when it's been taken down. Or sometimes it seems to take an inordinate amount of time for it to do so, or sometimes it starts sending requests before a restarting member is fully operational. A quick workaround is to manually edit the plugin's configuration file on each web server to comment-out the unwanted servers. The plugin will automatically detect and apply the changes within a minute or so and stop routing requests to those servers until you manually uncomment them. Plugin Configuration File LocationOn our AIX systems, the plugin configuration file is in a location like:
/usr
(If you're ever uncertain you're looking in the correct location, look for the WebS Plugin Configuration File ContentsWithin that file are many configuration items, most should never be manually edited, but the ones we care about for this purpose are the <PrimaryServers> elements within each <ServerCluster> element. The ServerCluster's "Name" attribute will tell you which element to edit. Then the PrimaryServers element in that ServerCluster will list each of the individual <Server> Cluster members which are also defined within ServerCluster. <ServerCluster ... Name="TestCluster" ...>
Removing a specific server from Plugin dispatchingThe only change we have to make is to comment-out the specific Server which we want to cease receiving requests. So to disable the TestApp-B server on serverB: <PrimaryServers>
Notes
Tags:  plugin web-server was cluster websphere ihs webserver failover |
||||||||||||||||||
WebSphere Web Server PluginAfter attending a webcast on the WebSphere Application Server 6.1 Plug-in, I thought I'd summarize the content I found helpful. OverviewThe plugin is a native module (DLL or .so) that is installed into the Web Server and is offered each HTTP request to determine whether WAS should handle it. It makes this determination based on the contents of the plugin-cfg.xml file which is normally auto-generated by WAS. I say, "normally", because it can be manually edited, but doesn't need to be for most operating scenarios. Note that many of these customizations can now be configured within the Administrative Console as well, which significantly reduces the need for manual file editing. This configuration is located under Servers -> Web Servers -> <Server Instance> -> Plug-in Properties. (Visiting this location in the Console is also a useful way to to locate the active plugin configuration file.) Operation MechanismThe configuration file specifies virtual hosts (IP names/addresses and ports) and URL paths which are serviced by WAS applications, enabling the plugin to determine which requests it can route to WAS and which it must leave for the HTTP server to handle. The file also contains values governing performance, maintenance, and failover, such as logging configuration and network timeouts. Finally, it contains the "transport" information used to forward matched requests to the appropriate Web Containers in WAS. That is, the IP name and port combinations of the different Cluster members' Web Container "Transport Chains". Affinity"Affinity" is the notion of sending a user to the same Cluster member (application server JVM) for each subsequent request after the initial one, if the application uses HTTP Sessions. This behavior is required by the JEE specification, and in WebSphere is the responsibility of the Web Server plugin. WebSphere maintains this affinity by appending a "Clone ID" or "Partition ID" to the "Session ID", which the plugin then compares against its configuration to correctly route subsequent requests. For further detail on the Session ID mechanics, see this post. New users, those without an existing Session, are distributed to Cluster members in either a weighted round-robin fashion or a random fashion. Round-robin is the default, and it will decrement each cluster member's "weight" each time it sends it a new request, until all members are less than zero, then they will all be reset to their starting values. Tips or Items of Note
Resources
Tags:  affinity plugin wlm apache websphere ihs web-server |
||||||||||||||||||
Tip: Finding exact version and applied patches of IBM HTTP Serverapachectl -V For instance Server version: IBM_ Tags:  tips web-server ihs patch httpd apache maintenance |