Configuration of SPWebPartsTest

For each web site, this test reports the time taken by the web parts in that site to load. In the event of undue delay in web part loading, the test also points administrators to the probable cause of the delay - is it because of processing delays in the web part? Is it because the web parts took too long to generate service calls? Or is it owing to inefficient queries to the backend database? Detailed diagnosis of the test also leads you to the precise service calls and queries that could have contributed to the slowness.

For this test to run and report metrics, the following pre-requisites should be fulfilled:

• A SharePoint Usage and Health Service application is created and is configured to collect usage and health data. To know how to create and configure this application, click here.

• The SharePoint Developer Dashboard should be enabled. To know the steps for enabling the SharePoint Developer Dashboard, click here.

The default parameters associated with this test are:

• The TEST PERIOD list box helps the user to decide how often this test needs to be executed.

• Specify the host for which the test is to be configured in the HOST text box.

• Specify the port used by the HOST in the PORT text box.

• Specify the port number of the SQL server hosting the usage database in the SQL PORT NUMBER text box.

• If the SQL server hosting the usage database is instance-based, then provide the instance name in the INSTANCE text box. If not, then set this to none.

• If the SQL server hosting the usage database is SSL-enabled, then set the SSL flag to Yes. If not, set it to No.

• In some Windows networks, NTLM (NT LAN Manager) may be enabled. NTLM is a suite of Microsoft security protocols that provides authentication, integrity, and confidentiality to users. NTLM version 2 (“NTLMv2”) was concocted to address the security issues present in NTLM. By default, the ISNTLMV2 flag is set to No, indicating that NTLMv2 is not enabled by default on the SQL server hosting the usage database. Set this flag to Yes if NTLMv2 is enabled on that SQL server.

• Specify the name of Microsoft SQL server that hosts the usage database to be accessed by this test in the DATABASE SERVER text box.

• Specify the name of the usage database that this test should access in the DATABASE NAME text box.

• Specify the credentials of a user who has read-only access to the usage database configured, in the DATABASE USER NAME and DATABASE PASSWORD text boxes. Then, confirm the password by retyping it in the CONFIRM PASSWORD text box.

• Specify the fully qualified name of the domain in which the Microsoft SQL server hosting the usage database operates in the DATABASE DOMAIN text box. For instance, your specification can be: sharepoint.eginnovations.com

• By default, the MAX ACCEPTABLE DURATION parameter is set to 3 (seconds). This implies that this test, by default, will report metrics for only those web sites containing one/more web parts that process requests for a duration longer than the 3 seconds. You can increase or decrease the value of this parameter, depending upon what you think is ‘slow’ in your environment. This way, you can configure the test to focus on only those web sites that contain slow or critical web parts alone.

• By default, this test does not track requests to the following URL patterns: *.js,*.css,*.jpeg,*.jpg,*.png,*.asmx,*.ashx,*.svc,*.dlll. If required, you can remove one/more patterns from this default list using the URL PATTERNS TO BE IGNORED FROM MONITORING parameter, so that such patterns are monitored, or can append more patterns to this list in order to exclude them from monitoring. For instance, to additionally ignore URLs that end with .gif and .bmp when monitoring, you need to alter the default specification as follows: *.js,*.css,*.jpeg,*.jpg,*.png,*.asmx,*.ashx,*.svc,*.dlll,*.gif,*.bmp 

• By default, this test ignores all requests to AjaxDelta pages. This is why, the IGNORE AJAXDELTA PAGES is set to Yes by default. If you want the test to track requests to the AjaxDelta pages as well, set this flag to No.

• Typically, farm-level metrics - eg., metrics on farm status, site collections, usage analytics - will not vary from one SharePoint server in the farm to another. If these metrics are collected and stored in the eG database for each monitored server in the SharePoint farm, it is bound to unnecessarily consume space in the database and increase processing overheads. To avoid this, farm-level metrics collection is by default switched off for the member servers in the SharePoint farm, and enabled only if the server being monitored is provisioned as the Central Administration site. Accordingly, the FETCH FARM MEASURES is set to If Central Administration by default. This default setting ensures that farm-level metrics are collected from and stored in the database for only a single SharePoint server in the farm.  

  If you want to completely switch-off farm-level metrics collection for a SharePoint farm, then set this parameter to No.

  Some high-security environments may not allow an eG agent to be deployed on the Central Administration site. Administrators of such environments may however require farm-level insights into status and performance. To provide these insights for such environments, you can optionally enable farm-level metrics collection from any monitored member server in the farm, even if that server is not provisioned as the Central Administration site. For this, set this parameter to Yes when configuring this test for that member server. 

• When monitoring a SharePoint 2010 server, this test has to be configured with the credentials of a domain user with the following privileges:

  • The user should be part of the SharePoint Farm Administrators group. To know how to add a user to this group, click here.

  • The user should have shell admin access to all databases in SharePoint. To know how to grant this privilege to a user, click here.

  • The user should be part of the following groups on the eG agent host:

    • Administrators

    • WSS_ADMIN_WPG

    • IIS_USRS

    • Performance Monitor Users

    • WSS_WPG

    • Users

    To know how to add a user to one of these groups, click here.

  • The user should have full control access to each web application that needs to be monitored on the Sharepoint server. To know how to grant this level of access to a user, click here.

  • The user should have read and execute access to the eG agent install directory. To know how to grant this level of access to a user, click here.

  It is recommended that you create a special user for this purpose and assign the aforesaid privileges to him/her. Once such a user is created, specify the domain to which that user belongs in the DOMAIN text box, and then, enter the credentials of the user in the DOMAIN USER and PASSWORD text boxes. To confirm the password, retype it in the CONFIRM PASSWORD text box.

• The DD FREQUENCY refers to the frequency with which detailed diagnosis measures are to be generated for this test. The default is 1:1. This indicates that, by default, detailed measures will be generated every time this test runs, and also every time the test detects a problem. You can modify this frequency, if you so desire. Also, if you intend to disable the detailed diagnosis capability for this test, you can do so by specifying none against DD FREQUENCY.

• To make diagnosis more efficient and accurate, the eG Enterprise suite embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the DETAILED DIAGNOSIS capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option.

  The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled:

  • The eG manager license should allow the detailed diagnosis capability

  • Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.

• If multiple components of the same component type are awaiting configuration, then an APPLY TO OTHER COMPONENTS check box will appear in this page. Clicking on this check box will allow you to apply the configuration to all/selected components of that type.

• Once the necessary values have been provided, clicking on the UPDATE button will register the changes made.

When changing the configuration for specific servers, a “*” beside the text box corresponding to the parameter signifies that these values have to be manually configured by the user. The parameter values that require to be configured will typically be prefixed with a “$” or contain a series of “*”. A value of "none" in the parameter value indicates that the corresponding parameter value can be changed if required.