Introduction
To improve your experience on The Forge, we’ve introduced the Forge API rate monitor. Here’s why:
Certain new or old modules may cause large numbers of server requests, which can result in a disrupted user experience without a clear, discernible cause. In a hosted environment, excessive requests can also negatively impact the server performance. Latency between the user and the server may also cause requests to complete markedly more slowly than they would in a locally hosted environment.
With the rate monitor, we aim to notify users of potential performance issues and to guide them efficiently in troubleshooting excessive API calls and ensuring a smooth experience on The Forge.
Patterns of Excessive API Calls
There are two usage patterns that are often disruptive to performance: Usage Spikes and Sustained Usage.
The numbers below are what we have chosen to represent these patterns, but the degree to which performance is disrupted may vary from case to case. Once one of these patterns occurs, additional calls will result in a warning.
Please note: The warnings will not impact functionality. We do not block these request, and if you do not encounter a performance dip, you can safely ignore these warnings.
Here, we’ll discuss the types in more detail and see an example warning for each.
-
Usage Spikes
- When there are at least 1000 calls in a minute to the same endpoint, it is considered a spike.
- Generally happens due to recursive calls, such as browsing the Assets Library and checking inside of each folder.
- May result in temporary performance dips, but generally performance returns to normal once the requests have completed.
- Every 100 additional requests issues another warning.
- Example warning:
-
Continuous Usage
- When an endpoint has been called at a rate of 1 request per second for the last 5 consecutive minutes, this is considered continuous usage.
- May be a result of an unintended endless loop in one of the modules.
- Will generally result in a feeling of slowness or lag that does not go away.
- Every 10 additional requests issues another warning.
- Example warning:
Troubleshooting
If you have encountered one of these warnings, you may not necessarily experience the associated performance impact. If the warning disappears and performance is not affected, you can safely ignore the warning and continue playing.
If you are experiencing poor performance, you will be able to recover performance by disabling the module which is making excessive API calls. Knowing which module the calls originate from can sometimes be obvious, if you receive the warning in response to a specific action, or if it goes away when you disable a specific module. Other times, it may be more difficult.
You can use your browser’s developer tools to find the source of the API calls.
When you encounter a UI warning related to rate monitor, detailed information can be found in your browser’s developer tools in the form of a stack trace. Here’s how you can access and understand this information:
-
Accessing Dev Tools:
- Right-click on any part of your browser page and select
InspectorInspect Elementfrom the dropdown. - (Alternatively, press F12 or Cmd+Opt+I on Mac)
- Once the developer tools pane opens, navigate to the
Consoletab to view logs and stack traces.
- Right-click on any part of your browser page and select
-
Viewing Traces:
- With the dev tools
Consoleopen, wait for the next rate monitor warning to appear. - Look for the
console.trace() Forge rate monitor:message in the console. - Example trace:
- Now hover over the files in the trace to see which module they belong to. In the example below, the module’s name has been hidden.
- Look for the words after
modules/to identify the module that the file is from.
- With the dev tools
In summary
- Try to disable the module that is causing poor performance.
- Use the dev tools console (F12) to help find out which module is making the API calls.
- Contact Forge Support if you have any problems.
We hope that this guide helps explain the rate limiter warnings you may see on The Forge, and also helps explain how to troubleshoot them.
Please reach out to us or make a post in this topic if you have any questions!
Note to Module Developers
If you’re a module developer and you need to recursively browse for assets in your module, please consider making use of the { recursive: true } option for the FilePicker.browse method provided by ForgeVTT_FilePicker.
if (ForgeVTT != undefined && ForgeVTT.usingTheForge) {
// Running on The Forge
// Specify the target directory, receive data for all dirs and subdirs in one request
const forgeAssetsLibrary = await FilePicker.browse("forgevtt", "/", {"recursive": true})
}
Please see Using the FilePicker to interact with the Assets Library - Docs - The Forge for a Forge-specific breakdown of how to browse without needing to recursively call an endpoint.