Starting with the release of Strategy ONE (March 2024), dossiers are also known as dashboards.
This article outlines the following topics for troubleshooting the new server governing mechanism, throttling:
During its operation, the Intelligence Server receives various types of requests. This includes time-critical ones, such as interactive dossier manipulations, as well as background requests, such as Smart Download inquiries from Library on iOS. When the Server is busy, it is ideal to prioritize the processing and execution of the time-bound interactive requests over the background ones, so that the processing time of the former can be maintained.
To prioritize execution and maintain the performance of interactive requests, Strategy 2021 introduces a new, automatic Server governing mechanism. The first part of this governing is to provide a throttling algorithm that rejects extraneous background requests, so that more system resources become available for interactive requests. This job throttling algorithm is designed to maintain the response time performance of interactive requests and only occurs when the Server is in a busy status. To this end, the Server is said to be busy if any of the followings is satisfied.
Note that background requests are rejected only if the server is busy (with the criteria mentioned above). Otherwise (i.e., when Server is idle), all background requests are still processed and provided full opportunity to occupy Server resources.
When not configured properly, however, job throttling may not deliver the promised response time improvement. This article provides a troubleshooting guideline for job throttling to prevent this issue.
To troubleshoot:
Symptom A: Degraded throughput for interactive jobs when I-Server received many Smart Download request.
|
|
|
|
|
| 1. On the I-Server machine, make sure that the Kernel → Info logging is enabled. To verify the throttling feature is indeed disabled, find the following NO entry in DSSErrors.log. [Kernel][Info] ... Registry setting value for enabling predictive request throttling: NO. 2. Enable the Rejected Count of the Predictive Caching Jobs performance counter using Strategy Diagnostics and Performance Logging Tool (MADPCfg_64.exe in Windows and mstrdiag in Linux). A zero amount here may also indicate that the throttling feature is disabled. Note: On the other hand, throttling is enabled if you encounter any of the followings: |
|
|
|
|
|
|
|
|
|
Symptom B: Inconsistent dossier execution time for mobile devices. Sometimes the response time is very fast, while other times it is very slow.
|
|
|
|
|
|
|
|
|
|
|
|
Symptom C: Many Smart Download requests from clients apps (i.e., Mobile and Library on iOS and Android) are being rejected. Here, Smart Downloads is also preferred as "Predictive caching."
|
|
|
|
|
|
|
|
|
|
|
|
|
| Note: The log entry above indicates that more than 80% of Command PU threads (the ones for processing incoming requests/commands) are occupied. By default, the Server has 40 of such threads. The Command PUs can be highly-occupied due to various factors (including the number of incoming commands, CPU & memory utilization, other running OS-level processes, etc.). |
|
If the the troubleshooting workflow above does not solve your problem, the immediate action is to verify whether the throttling feature works properly. The feature works properly if ALL of these three behaviors can be observed:
This section starts by explaining how to verify these behaviors. For a more practical, step-by-step guideline, please watch the video recording at the end of this section.
You may use the two main tools to verify whether the throttling feature is working properly:
DSSErrors.log.The following will be printed when I-Server becomes busy.
... [Kernel][Info] ... [SID:<session_id>][OID:<dossier_id>] The server is in idle state and accepting Smart Download requests
... [Kernel][Info] ... [SID:<session_id>][OID:<dossier_id>] The server is in idle state and accepting Smart Download requests
... [Kernel][Job Trace] ... [SID:<session_id>][OID:<dossier_id>] Rejecting predictive caching job request because server is in busy status.
DSSErrros.log. A simpler way is to use Performance Counters to display the count of rejected and accepted predictive caching requests. This is done by accessing the “Performance Configuration” of the Strategy Diagnostic and Performance Logging Tool and then enabling the
Accepted Count of Predictive Caching Jobsand
Rejected Count of Predictive Caching Jobscounters. This will produce a time-stamped
.csvfile (named
DSSPerformanceMonitor.csvin the example below). From this file, you can easily determine whether there is any rejected predictive caching request.

DSSErrors.logand the Performance Counters tools in hand, you can verify that the throttling feature is working properly by following these steps.
DSSErrors.logdoes NOT contain any entry mentioned above. Using the Performance Counters, you could also ensure that NEITHER the
Accepted Count of Predictive Caching Jobsnor the
Rejected Count of Predictive Caching Jobsincreases.

DSSErrors.logand verify either (1) I-Server has never entered a busy status, or (2) it has returned to idle status. To do this, you can kill or wait until all interactive jobs are finished. Additionally, you should also make sure that the predictive caching feature is disabled from Strategy Mobile and Library on iOS and Android. This is accessible from the “Smart Download” part of the “Options → Preferences” page (see screenshot above). To send a predictive caching request, determine the target project and Dossier IDs (these should exist and operational in your metadata), and then send the following REST API commands to StrategyLibrary. Here, the first one is for project login while the predictive caching request is actually sent by the POST command in line 2.
curl -X POST "http://<library_hostname>:8080/MicroStrategyLibrary/api/auth/login" -H "accept: application/json" -H "Content-Type: application/json" -d "{"username":"<user_name>","password":"<password>","loginMode":1,"maxSearch":3,"workingSet":10,"changePassword":false,"newPassword":"string","metadataLocale":"en_us","warehouseDataLocale":"en_us","displayLocale":"en_us","messagesLocale":"en_us","numberLocale":"en_us","timeZone":"UTC","applicationType":35}"
curl -X POST "http://<library_hostname>:8080/MicroStrategyLibrary/api/dossiers/<dossier_id>/executionResult?resultType=binary" -H "accept: /" -H "X-MSTR-AuthToken: <x_mstr_token_from_login>" -H "X-MSTR-ProjectID: <project_id>" -H "Content-Type: application/json" -d "{"include":[],"mobilePrecaching":true}"DSSErrors.logdoes not contain any entry that indicates I-Server becomes busy nor any predictive caching request becomes rejected. You could also ensure that the
Accepted Count of Predictive Caching Jobsincreases while the
Rejected Count of Predictive Caching
Jobsremains zero.
DSSErrors.logto verify that I-Server has entered a busy status. Then, trigger a predictive caching request through the
/api/dossiers/<dossier_id>/executionResultREST API endpoint as exemplified above. After that, re-open the
DSSErrors.logand verify that I-Server the predictive caching request is rejected. If enabled, you could also verify that the
Rejected Count of Predictive Caching Jobsin the Performance Counters is increased.
A more detailed step-by-step example to verify whether job throttling works properly is given in the video below. Note that the video start with some preparatory steps. The part that verifies of job throttling’s functionality starts at timestamp 2:15.
A background-generated Smart Download request is throttled when the following thresholds are met. Note that the thresholds, namely,
AvailableMemoryThresholdInPercentage,
JobWaitingCountThresholdInPercentOfCPUCores,
CommandRunningThreadsThresholdInPercentage, are also specified in the table below and can be configured through Registry Editor in Windows and
MSIReg.regfile in Linux.
50and Strategy does not recommend changing this value.
50and Strategy does not recommend changing this value.
To improve performance, the above-mentioned Server states are cached and have a refresh interval of
ServerBusyRefreshIntervalInSecondsseconds. According to the table below, the default interval is
5seconds. Strategy does not recommend changing this value.
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\MicroStrategy\DSS Server\Predictive Request Throttling\Server Busy Thresholdspath through Registry Editor in Windows.
HKEY_LOCAL_MACHINE\SOFTWARE\MicroStrategy\DSS Server\Predictive Request Throttling\Server Busy Thresholdspath inside the
MSIReg.regfile.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|