Overview
REST API response time can be affected by many factors, including system characteristics such number of cores and memory, as well as the amount of data in the TOS database and the amount of data returned by an API call.
Indexed Data
For faster searching, TOS indexes commonly accessed data. The following APIs access indexed data, and will therefore generally have a faster response time.
- Rule Usage
- Rule Search
- Network Object Search (Object Browser)
Device Data
Device data (for example, security rules or network objects) is included in revisions that are retrieved by TOS from the device. To make this data available, these revisions must be parsed and added to the Policy Model Cache in the TOS database. Data that is stored in the Policy Model Cache is readily available for fast retrieval by the APIs. All other data is stored unparsed and must be parsed prior to becoming available from the Policy Model Cache. This data will have a lengthier retrieval time.
Data regarding the latest policy revision for every monitored device is stored in the Policy Model Cache. Therefore, API calls to the retrieve the latest revisions or device data will generally have a faster response time. If a historical revision is accessed via the APIs, the data for that policy will remain in the Policy Model Cache for a period of time.
The first API call to retrieve historical data about a device will parse and store all the data in the Policy Model Cache, and will have a slower response time. Subsequent API calls to retrieve other data for the same revision will have a faster response time.
Device data includes the following:
- Security Rules
- NAT Policies
- Network Objects
- Services and Ports
- Time Objects
- Crypto Maps
- Application IDs
- Additional Parameters
- Device Interfaces and Zones
- Policies and Sub-Policies
We recommend that API calls to retrieve historical data should be made in the background, or alert the user with a message (for example “Processing in progress. Please wait”) and changing the cursor icon.
Managing Generic Devices in the Interactive Map
If you are modifying multiple generic devices in consecutive API calls, you can set update_topology=false on all API calls except for the last one. On the last call, set update_toplogy=true or call the topology sync API call to synchronize the topology map.
Topology and Policy Analysis APIs
APIs that trigger topology and policy analysis calculations require internal TOS processing, and will have a slower response time. We recommend that you call these APIs in the background, or alert the user with a message (for example “Processing in progress. Please wait”) and changing the cursor icon.
The APIs that trigger topology and policy analysis calculations are:
- Path finder
This API cannot be executed more than 10 times in parallel
- Run Policy Analysis query
- Change Authorization
- Unified Security Policy - Access Request Violations
- Find Shadowing rules
Recommended and Maximum REST API Requests per Second
The following table lists the recommended and maximum REST API requests per second that you can use in your applications.
| Average Response Time | Recommended Requests/sec | Maximum Requests/sec |
|---|---|---|
| <1 seconds | 4 | 9 |
| 1-2 seconds | 1 | 3 |
| 2-5 seconds | 0.5 | 3 |
| 5-10 seconds | 0.25 | 1 |
| 10-15 seconds | 0.2 | 1 |
| 15-20 seconds | 0.15 | 0.5 |
| 20-30 seconds | 0.1 | 0.33 |
Estimating Average REST API Response Time
To estimate the average API response time for your environment, we recommend that you time how long it takes to return the results for approximately 10 API calls. Use this data to calculate your average response time. You can measure the response time manually using a stop watch, or via the linux time command.
For example, to measure the actual amount of time it takes to retrieve all the rules for a single device:
# time curl -u <admin_user>:<admin_password> -k --http1.0 https://<st_URL>/securetrack/api/devices/1/rules
...
real 0m6.905s
user 0m0.030s
sys 0m0.050s
The results displayed in real 0m6.905s is the time it actually took for the server to return the results. Repeat this ten times, and use the results to calculate the average response time. Average response time can vary between API calls, so calculate the average response time for each API you plan on using.
You can estimate response time for any commands that are relevant for your programming requirements. For example, to determine the average response time to retrieve access request violations, use the average response time from ten Access Request Violations API calls. To determine the average response time to retrieve rules from a device, use the average response time from ten Get Rules API calls. We recommend that you use devices that contains many rules, so that your results will better model your environment.
