Cloud Platform
Staying under Acquia Search limits
Subscribers with websites that use the Acquia Search platform have limits for some or all of the following resources:
If the limits are consistently met or exceeded, Acquia reserves the right to restrict the website’s use of the shared search resources or move your website to a dedicated Acquia Search instance at your expense. Acquia generally does not block access to your Solr index. However, a block may occur in an emergency where your or another customer’s data or service could be impacted.
If you have not yet reached your usage limits, you can take proactive steps to prevent your website from exceeding them. Consider the following factors as you plan for future usage:
What is your projected growth if you are indexing files?
Large attachments can cause problems for your index.
If you are concerned that you may exceed your limits, your next step is to create a Support ticket or contact your account manager to get help to determine the best fit for your website.
If you have exceeded your subscription limits, the following possible actions can be taken:
Acquia Search includes a built‑in flood control (rate‑limit) mechanism to protect shared Solr infrastructure and your subscription entitlements.
Flood control monitors how many search and index requests are sent to Solr over a sliding time window. If too many requests of the same type occur in a short period, additional requests can be temporarily blocked. After this occurs, you can identify errors such as the following:
HTTP status code 429
Messages that refer to “The Acquia Search flood control mechanism has blocked a Solr query due to API use limits”
Flood protection has blocked request of type select
Flood control exists to protect your site from:
Abusive or misconfigured crawlers
Application bugs that send excessive queries or updates
Import or batch processes not tuned for Solr
Acquia Search uses different flood control rules for:
/select requests (end‑user search queries)
/update requests (index and content updates)
In normal traffic, most sites never hit these limits. If your site hits flood control frequently, you must do the following:
Review your Acquia metrics and logs to identify which paths, jobs, or integrations send high volumes of Solr requests.
Check for new features that increase search use (autocomplete, recommendations, faceted navigation, etc.).
Review your non‑production environments to ensure they do not generate unnecessary search traffic.
For detailed error examples and configuration options, including how to adjust limits per request type, visit The Acquia Search flood control mechanism has blocked a Solr query due to API use limits.
After you have a high‑traffic or index event such as a large content import, site launch, or campaign:
Plan your index jobs to:
Use larger batch sizes and fewer requests.
Run imports during off‑peak hours.
Monitor:
Search and index rates
HTTP error codes (to include 429)
Overall Solr performance and throughput
Contact Acquia Support if you expect sustained high use that could affect your Acquia Search subscription limits, such as queries, documents, and disk space.
If necessary, you or your development team can temporarily adjust flood‑control limits at the application level to stay within your contractual entitlements. Refer to the troubleshooting article for configuration details and examples: The Acquia Search flood control mechanism has blocked a Solr query due to API use limits.
A search query counts as any Solr request that retrieves content from a Search application.
| Action | Description |
|---|---|
| Search queries | One Solr request is counted when a user types a search term, and then presses Enter or clicks the Search button. |
| Filter/Facet selection | One Solr request is counted when a user clicks a facet even if the search term does not change. |
| Solr Autocomplete vs. SearchStax Auto-Suggest | Each keystroke in the search box can be counted as a request. Each response is counted as a query. However, it depends on your autocomplete configuration:
|
| Pagination | One Solr request is counted when a user navigates the pager of the search results page. |
| API queries | One Solr request is counted when an API call is made to Solr. It also applies to the non-production environments. |
Acquia Search uses three metrics for your subscription: disk storage size, number of Solr requests from Drupal, and the number of documents in the index. You can use different strategies to reduce usage in one or more of these areas.
All of your Acquia subscription’s Solr indexes (production and non-production) count toward your limits. Reduce usage of some or all non-production indexes, or remove indexes entirely to stay within your subscription bounds.
Several issues can trigger a high number of requests to your Acquia Search Solr backend:
| Situation | Action |
|---|---|
| Autocomplete widgets powered by Solr |
|
| Usage of More Like This content recommendation blocks | Cache these blocks or reduce their usage. |
| Elevated traffic that triggers Solr queries | Often caused by crawlers following links that trigger Solr requests.
|
If you are using Drupal 7, one way to understand what data is being sent to your Solr index is to use the Solr Devel module, which adds a Devel > Solr tab on each entity. This enables you to see what’s already in your Solr index and what data would be sent if you were to index an item.
If you are not careful about what you are indexing, the size of your Solr index can increase rapidly, consuming excessive disk space. There are several potential causes:
| Situation | Action |
|---|---|
Automated Solr optimize isn’t running | The Optimize Solr operation is usually invoked weekly by Drupal modules and is responsible for reclaiming disk space after deletes and garbage collection.
|
| Indexing too many fields or entity data | This often occurs when indexing nodes with many comments.
|
| Indexing large attachments with large amounts of text | Large PDF or text files can fill disk space quickly. |
The relationship between the number of Drupal entities and number of Solr documents is not always one-to-one; Drupal can process a single entity such as a node or a user into multiple Solr documents. For example:
Cloud Platformnode/1 has three attached files. This can create four Solr documents; one for the node, and one for each attachment.node/1 has field data in three languages. This may create four Solr documents; one for each language.To reduce the number of documents in your Solr index:
robots.txt directives to avoid spiders accessing search results pages or facet links.For more information, see Block excessive crawling of Drupal Views or search results.
| The Index immediately option is enabled in Search API. | Compounded by mass importing or editing of content.
|
| The Search 404 module is enabled. | Made worse by crawlers and traffic.
|
| Mass content edits, imports or migrations | Disable indexing while doing any mass content handling. |
| Out of date modules | Ensure your modules are up to date. |
If this content did not answer your questions, try searching or contacting our support team for further assistance.
If you are concerned that you may exceed your limits, your next step is to create a Support ticket or contact your account manager to get help to determine the best fit for your website.
If you have exceeded your subscription limits, the following possible actions can be taken:
Acquia Search includes a built‑in flood control (rate‑limit) mechanism to protect shared Solr infrastructure and your subscription entitlements.
Flood control monitors how many search and index requests are sent to Solr over a sliding time window. If too many requests of the same type occur in a short period, additional requests can be temporarily blocked. After this occurs, you can identify errors such as the following:
HTTP status code 429
Messages that refer to “The Acquia Search flood control mechanism has blocked a Solr query due to API use limits”
Flood protection has blocked request of type select
Flood control exists to protect your site from:
Abusive or misconfigured crawlers
Application bugs that send excessive queries or updates
Import or batch processes not tuned for Solr
Acquia Search uses different flood control rules for:
/select requests (end‑user search queries)
/update requests (index and content updates)
In normal traffic, most sites never hit these limits. If your site hits flood control frequently, you must do the following:
Review your Acquia metrics and logs to identify which paths, jobs, or integrations send high volumes of Solr requests.
Check for new features that increase search use (autocomplete, recommendations, faceted navigation, etc.).
Review your non‑production environments to ensure they do not generate unnecessary search traffic.
For detailed error examples and configuration options, including how to adjust limits per request type, visit The Acquia Search flood control mechanism has blocked a Solr query due to API use limits.
After you have a high‑traffic or index event such as a large content import, site launch, or campaign:
Plan your index jobs to:
Use larger batch sizes and fewer requests.
Run imports during off‑peak hours.
Monitor:
Search and index rates
HTTP error codes (to include 429)
Overall Solr performance and throughput
Contact Acquia Support if you expect sustained high use that could affect your Acquia Search subscription limits, such as queries, documents, and disk space.
If necessary, you or your development team can temporarily adjust flood‑control limits at the application level to stay within your contractual entitlements. Refer to the troubleshooting article for configuration details and examples: The Acquia Search flood control mechanism has blocked a Solr query due to API use limits.
A search query counts as any Solr request that retrieves content from a Search application.
| Action | Description |
|---|---|
| Search queries | One Solr request is counted when a user types a search term, and then presses Enter or clicks the Search button. |
| Filter/Facet selection | One Solr request is counted when a user clicks a facet even if the search term does not change. |
| Solr Autocomplete vs. SearchStax Auto-Suggest | Each keystroke in the search box can be counted as a request. Each response is counted as a query. However, it depends on your autocomplete configuration:
|
| Pagination | One Solr request is counted when a user navigates the pager of the search results page. |
| API queries | One Solr request is counted when an API call is made to Solr. It also applies to the non-production environments. |
Acquia Search uses three metrics for your subscription: disk storage size, number of Solr requests from Drupal, and the number of documents in the index. You can use different strategies to reduce usage in one or more of these areas.
All of your Acquia subscription’s Solr indexes (production and non-production) count toward your limits. Reduce usage of some or all non-production indexes, or remove indexes entirely to stay within your subscription bounds.
Several issues can trigger a high number of requests to your Acquia Search Solr backend:
| Situation | Action |
|---|---|
| Autocomplete widgets powered by Solr |
|
| Usage of More Like This content recommendation blocks | Cache these blocks or reduce their usage. |
| Elevated traffic that triggers Solr queries | Often caused by crawlers following links that trigger Solr requests.
For more information, see Block excessive crawling of Drupal Views or search results. |
| The Index immediately option is enabled in Search API. | Compounded by mass importing or editing of content.
|
| The Search 404 module is enabled. | Made worse by crawlers and traffic.
|
| Mass content edits, imports or migrations | Disable indexing while doing any mass content handling. |
| Out of date modules | Ensure your modules are up to date. |
If you are using Drupal 7, one way to understand what data is being sent to your Solr index is to use the Solr Devel module, which adds a Devel > Solr tab on each entity. This enables you to see what’s already in your Solr index and what data would be sent if you were to index an item.
If you are not careful about what you are indexing, the size of your Solr index can increase rapidly, consuming excessive disk space. There are several potential causes:
| Situation | Action |
|---|---|
Automated Solr optimize isn’t running | The Optimize Solr operation is usually invoked weekly by Drupal modules and is responsible for reclaiming disk space after deletes and garbage collection.
|
| Indexing too many fields or entity data | This often occurs when indexing nodes with many comments.
|
| Indexing large attachments with large amounts of text | Large PDF or text files can fill disk space quickly.
|
The relationship between the number of Drupal entities and number of Solr documents is not always one-to-one; Drupal can process a single entity such as a node or a user into multiple Solr documents. For example:
node/1 has three attached files. This can create four Solr documents; one for the node, and one for each attachment.node/1 has field data in three languages. This may create four Solr documents; one for each language.To reduce the number of documents in your Solr index:
If this content did not answer your questions, try searching or contacting our support team for further assistance.