Tchater maintenant avec le support
Tchattez avec un ingénieur du support

Foglight for Microsoft DOT NET 5.9.9 - Application Servers Administration and Configuration Guide

Managing request types and topology object creation

If you are managing many request types, updating the Nexus recording settings to transform several different request types into the same request type can improve performance on the Management Server.
The request model that the Nexus uses generates several associated internal topology object types for each request type. This may result in an extremely high topology object count. In addition, rules are applied to each topology object and this may increase the processing load on the Management Server.
 
* 
TIP: The higher the topology object count, the higher the processing load on your Management Server. As a result, the Application Servers Monitor > Requests view is overloaded and performs slowly.
The default URL transformation rules described in Setting rules for transforming URLs were implemented to mitigate this effect. These rules apply to new installations only, not to upgrades.
For example, deployed applications may contain many request types. Poor performance of the Management Server may be due to the parameters being encoded in the URL, rather than using separate URL parameters.
Example of the parameters encoded in the URL:
GET /foo&categoryID=123
GET /foo&categoryID=223
GET /foo&categoryID=233
GET /foo&categoryID=323
Foglight for Application Servers treats each of the above requests as a separate request type, each having a single associated topology object.
Example of separate URL parameters:
GET /foo?categoryID.123
GET /foo?categoryID.223
GET /foo?categoryID.233
GET /foo?categoryID.323
Here the GET/foo request type has just one associated topology object, which has a count of four calls.

Setting rules for filtering requests

Use filters to configure the Nexus to reduce the total number of request types being monitored, which decreases both overhead and storage requirements. Filtering can be configured to include some requests and exclude others. Regular expression pattern matching can be used to determine which requests are included and which are excluded. You can also match requests using literal strings. For more information about using regular expressions, see Appendix: Regular Expressions in the Foglight for Application Servers User Guide.
Filtering occurs after request separation and URL transformation rules are applied. As a result, the filters can refer to parameter names and values from request separation, and must reference the transformed URL. If a request is filtered out, then it cannot be traced. Filtering rules are set in the Nexus recording settings.
When setting up rules for filtering requests, keep in mind that the FilteringRules are applied first and then the FilterDefault setting is applied.
By default, the filter is configured to collect metrics for the following request types:
•
HTTP requests, using the (GET|POST|...) filter
•
RMI and JMS requests, using the “:” filter
Keys and values can be used to customize the FilteringRules parameter.
•
Keys — Strings or regular expressions
•
Values — Booleans that define whether the request is filtered out. If it is filtered out, the request is not monitored.
 
* 
NOTE: You can include the HTTP method in this rule.
The following filtering rules are applied first:
FilteringRules = {
/\.(gif|GIF|Gif)$/ : false,
/\.(jpg|jpeg|JPG|JPEG|Jpg|Jpeg)$/ : false,
/\.(png|PNG|Png)$/ : false,
/\.(css|CSS|Css)$/ : false,
/\.(js|JS|Js)$/ : false,
/\.(ico|ICO|Ico)$/ : false,
/^(GET|POST|DELETE|HEAD|OPTIONS|PUT|TRACE)/ : true,
/:/ : true,
};
Figure 1. These filtering rules appear in the UI as the following list:
If none of the rules match the URL, and the FilteringDefault setting is enabled, then the FilteringDefault setting is applied.

Adjusting the number of sampled requests

On the Application Servers dashboard, the Requests view shows the Sampled Breakdowns and the number of requests that are sampled. You can control how many requests are sampled for the time period. Collecting fewer samples reduces the overhead that the agent places on the application server.
To adjust the number of sampled requests:
1
On the navigation panel, under Dashboards, click Application Servers > Administration.
2
On the Application Servers Administration dashboard, click the Nexuses tab.
3
On the Nexuses view, do one of the following:
•
On the Agents tab, click the name of the Nexus that is using the configuration you want to edit. Click Text edit recording settings.
Or
•
On the Recording Settings tab, click the name of the configuration you want to edit. Click Manage. On the Nexus Configuration view, click recording. Click Text edit.
The recording.config file opens in a text editor.
4
Change, or add, the following property:
SamplingOverhead = 0.0;
Values from 0.0 to 1.0 are valid for this property. A smaller value yields a smaller sample.
5
Save your changes.
To view the results of the changes, let the application run for a while and then return to the Application Servers dashboard and select Requests. Click the Sampled Breakdowns tab in the Request Charts section and observe the change.

Collection details

Use the Collection Details tab of the Nexus Recording editor to set request detail rules and default levels.
Request detail collection occurs after separation rules, URL transformation rules, and filtering rules are applied. There are two settings used for the collection of Requests details: RequestDetailRules and RequestDetailDefault. By default, only the Individual Requests are enabled. All other settings are undefined.
Figure 2. The Collection Details tab.
Request Detail rule
Keys and values can be used to customize the RequestDetailRule parameter.
•
Keys — Strings or regular expressions to match a URL
•
Values — Specify which request detail information to collect
 
* 
NOTE: It is not recommended to set the default to collect all breakdown details. Instead, consider creating appropriate request detail rules to selectively sample and exclude requests before modifying this setting.
Request Detail default
The following values are used to collect request details, and may appear in any order and combination:
•
Tier — Breaks request timing down for application and database tiers
•
Component Technology — Breaks request timing down for monitored components (for example, EJBs and JSP/Servlets)
•
Application — Breaks request timing down for multiple applications
•
Server — Breaks request timing down across individual application servers
•
Individual Requests — Breaks request timing down into individual requests. Also can display breakdowns in the Response Time Explorer when used with Foglight for Application Operations. This option is enabled by default.
 
* 
TIP: For more information about configuring URL transformations specifically for APM, see Configuring APM URL transformation .
For example:
The following procedure describes how to collect:
•
component technology breakdown detail for all requests that perform a transfer
•
all breakdown details for login.jsp
•
server breakdown details for index.do
•
Tier Breakdown information for all requests that do not match the other rules
In the Nexus Recording editor:
1
Open the Nexus Recording editor, as described in Editing the Nexus recording settings .
2
Click the Collection Details tab.
3
Click Edit beside RequestDetailRules.
4
In the Settings Editor, click Add to add each rule (one per row).
5
Click OK to close the Settings Editor.
6
In the RequestDetailDefault list, click the check box for Tier breakdowns.
7
Click Save to save your settings, or Cancel to discard any changes.
In the text editor:
RequestDetailRules = {
/.*\/transfer\-.*\.jsp$/ : ("ComponentTechnologyBreakdown"),
/.*\/login\.jsp$/ : ("TierBreakdown", "ApplicationBreakdown"),
"/index.do" : ("ServerBreakdown"),
};
 
RequestDetailDefault = ("TierBreakdown");
Documents connexes

The document was helpful.

Sélectionner une évaluation

I easily found the information I needed.

Sélectionner une évaluation