{"__v":2,"_id":"578821e2e516ba0e003047bc","category":{"project":"56be3387be55991700c3ca0d","version":"56be3388be55991700c3ca10","_id":"5787da96b008c91900aae865","__v":0,"sync":{"url":"","isSync":false},"reference":false,"createdAt":"2016-07-14T18:31:50.937Z","from_sync":false,"order":3,"slug":"troubleshooting","title":"Troubleshooting"},"parentDoc":null,"project":"56be3387be55991700c3ca0d","user":"5633ec9b35355017003ca3f2","version":{"__v":8,"_id":"56be3388be55991700c3ca10","project":"56be3387be55991700c3ca0d","createdAt":"2016-02-12T19:33:28.313Z","releaseDate":"2016-02-12T19:33:28.313Z","categories":["56be3389be55991700c3ca11","57646709b0a8be1900fcd0d8","5764671c89da831700590782","57646d30c176520e00ea8fe5","5764715d4f867c0e002bc8e3","57698fa2e93bfd190028815c","576c2af16c24681700c902da","5787da96b008c91900aae865"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"1.0.0","version":"1.0"},"updates":[],"next":{"pages":[],"description":""},"createdAt":"2016-07-14T23:36:02.315Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":0,"body":"## What is a 429 error?\n\nWe enforce a limit on the number of simultaneous requests that can be made to a server (in the case of Websolr, an index); these are called concurrent connections. This limit is enforced to mitigate against DoS attacks, whether intentional or unintentional. The limit scales with plan level on our shared tier plans. Single tenant plans don't have concurrent limits beyond the limitations of the underlying hardware.\n\n## How do concurrent connections affect thoughput?\n\nAssume a typical request takes 100ms. With a 5x limit, you could serve 50 requests per second. Reducing latency to, say, 50ms (perhaps with field caching or reducing complexity) would double the available throughput to 100 requests per second.\n\nBesides just upgrading plan level, one method to improving thoughput is to batch your updates. This entails sending updates in batches rather than one at a time. If you have a bunch of workers handling document updates, you should decrease that number to ensure that you don't have too many trying to send documents at once. This frees up connections to handle search traffic. Keep in mind that both searches and updates count as concurrent connections, so if you have 5 workers sending updates and a user submits a search, something will fail with an HTTP 429.\n\nAnother strategy for avoiding concurrency limits is to use routing headers. This allows you to send searches to your replica and updates to your primary. This can be helpful in minimizing latency by distributing load over both Solr cores. The caveat here is that this approach only applies to indices that support replication, and where near real-time results aren't a requirement.\n\n## Concurrent connection plan limits on Websolr\n[block:parameters]\n{\n  \"data\": {\n    \"0-0\": \"Cobalt\",\n    \"0-1\": \"5\",\n    \"1-0\": \"Chromium\",\n    \"1-1\": \"5\",\n    \"2-0\": \"Platinum\",\n    \"2-1\": \"10\",\n    \"3-0\": \"Palladium\",\n    \"3-1\": \"10\",\n    \"4-0\": \"Tungsten\",\n    \"4-1\": \"20\",\n    \"5-0\": \"Titanium\",\n    \"5-1\": \"As needed\",\n    \"h-0\": \"Plan name\",\n    \"h-1\": \"connection limit\"\n  },\n  \"cols\": 2,\n  \"rows\": 6\n}\n[/block]\n## Managing Traffic\n\nOur general recommendations for managing high volumes of traffic are:\n\n- When performing a bulk reindex, update operations should send documents in batches of between 100 and 1,000 per request, from one or two indexing processes.\n- Ongoing incremental updates (e.g., generated by user activity) should be processed through a queue, so they can be paused, throttled or retried as needed.\n- High volumes of search traffic can also benefit from a layer of caching on the application side.\n\nBeyond that, we can also increase our concurrent request limits for dedicated cluster customers (Titanium and custom plans) for very high traffic sites which may require hundreds of concurrent requests.","excerpt":"","slug":"429-too-many-requests","type":"basic","title":"429 Too Many Requests"}

429 Too Many Requests


## What is a 429 error? We enforce a limit on the number of simultaneous requests that can be made to a server (in the case of Websolr, an index); these are called concurrent connections. This limit is enforced to mitigate against DoS attacks, whether intentional or unintentional. The limit scales with plan level on our shared tier plans. Single tenant plans don't have concurrent limits beyond the limitations of the underlying hardware. ## How do concurrent connections affect thoughput? Assume a typical request takes 100ms. With a 5x limit, you could serve 50 requests per second. Reducing latency to, say, 50ms (perhaps with field caching or reducing complexity) would double the available throughput to 100 requests per second. Besides just upgrading plan level, one method to improving thoughput is to batch your updates. This entails sending updates in batches rather than one at a time. If you have a bunch of workers handling document updates, you should decrease that number to ensure that you don't have too many trying to send documents at once. This frees up connections to handle search traffic. Keep in mind that both searches and updates count as concurrent connections, so if you have 5 workers sending updates and a user submits a search, something will fail with an HTTP 429. Another strategy for avoiding concurrency limits is to use routing headers. This allows you to send searches to your replica and updates to your primary. This can be helpful in minimizing latency by distributing load over both Solr cores. The caveat here is that this approach only applies to indices that support replication, and where near real-time results aren't a requirement. ## Concurrent connection plan limits on Websolr [block:parameters] { "data": { "0-0": "Cobalt", "0-1": "5", "1-0": "Chromium", "1-1": "5", "2-0": "Platinum", "2-1": "10", "3-0": "Palladium", "3-1": "10", "4-0": "Tungsten", "4-1": "20", "5-0": "Titanium", "5-1": "As needed", "h-0": "Plan name", "h-1": "connection limit" }, "cols": 2, "rows": 6 } [/block] ## Managing Traffic Our general recommendations for managing high volumes of traffic are: - When performing a bulk reindex, update operations should send documents in batches of between 100 and 1,000 per request, from one or two indexing processes. - Ongoing incremental updates (e.g., generated by user activity) should be processed through a queue, so they can be paused, throttled or retried as needed. - High volumes of search traffic can also benefit from a layer of caching on the application side. Beyond that, we can also increase our concurrent request limits for dedicated cluster customers (Titanium and custom plans) for very high traffic sites which may require hundreds of concurrent requests.