{"_id":"567b001117368a0d009a6e10","project":"5633ebff7e9e880d00af1a53","__v":3,"parentDoc":null,"version":{"_id":"5633ec007e9e880d00af1a56","project":"5633ebff7e9e880d00af1a53","__v":15,"createdAt":"2015-10-30T22:15:28.105Z","releaseDate":"2015-10-30T22:15:28.105Z","categories":["5633ec007e9e880d00af1a57","5633f072737ea01700ea329d","5637a37d0704070d00f06cf4","5637cf4e7ca5de0d00286aeb","564503082c74cf1900da48b4","564503cb7f1fff210078e70a","567af26cb56bac0d0019d87d","567afeb8802b2b17005ddea0","567aff47802b2b17005ddea1","567b0005802b2b17005ddea3","568adfffcbd4ca0d00aebf7e","56ba80078cf7c9210009673e","574d127f6f075519007da3d0","574fde60aef76a0e00840927","57a22ba6cd51b22d00f623a0"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"1.0.0","version":"1.0"},"category":{"_id":"567b0005802b2b17005ddea3","pages":["567b001117368a0d009a6e10","567b00307c40060d005603e7","567b039a7c40060d005603ec"],"project":"5633ebff7e9e880d00af1a53","version":"5633ec007e9e880d00af1a56","__v":3,"sync":{"url":"","isSync":false},"reference":false,"createdAt":"2015-12-23T20:11:49.377Z","from_sync":false,"order":1,"slug":"best-practices","title":"Best Practices"},"user":"5633ec9b35355017003ca3f2","updates":[],"next":{"pages":[],"description":""},"createdAt":"2015-12-23T20:12:01.655Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":4,"body":"Bonsai implements connection management as a metered plan resource. Our connection management is designed to help model and encourage best practices for using Elasticsearch efficiently at different cluster sizes.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Read, Write & Bulk Requests\"\n}\n[/block]\nRequests are categorized into three groups, based on the HTTP method and sometimes the path. The first group is read requests, including `HEAD`, `GET`, `OPTIONS` and `POST`s to `_search` and related search endpoints. The second group is for Bulk API requests: any request to a `_bulk` endpoint. Finally, all other write requests.\n\nIt's worth noting that Bulk API updates are grouped separately from other writes. This is because the use of the Bulk API is encouraged as the more efficient means of data ingress into Elasticsearch. Other single-document updates are helpful for maintaining synchronization over time with your primary database, but should be avoided as a means for mass ingress of data.\n\n[block:callout]\n{\n  \"type\": \"info\",\n  \"title\": \"ProTip: Use a Queue\",\n  \"body\": \"For best performance and reliability, we recommend that most updates be stored in a durable message queue for asynchronous grouping and processing in batches. Consider message queues such as Apache Kafka, AWS Kinesis, IronMQ, Disque, Redis, RabbitMQ, and so on.\"\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Measuring Concurrency\"\n}\n[/block]\nConcurrency limits are measured in terms of active requests in-flight to Elasticsearch. An otherwise idle HTTP keep-alive connection is not tracked toward this limit; we encourage you to maintain a reasonably sized pool of keep-alive connections to reduce the setup cost of each connection and speed up your average request.\n\nWhen the number of in-flight requests exceeds the cluster's concurrency limit, we queue incoming requests and serve them on a first-come-first-served basis. This queue is a best-effort mechanic on our end, intended to smooth out fluctuation and protect Elasticsearch from becoming overloaded when a cluster's traffic is operating near its connection limits. It is not a durable message queue, nor does it replace client-side queueing for updates.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Optimizing Bulk Api Usage\"\n}\n[/block]\nFor example, consider a cluster on a plan that offers bulk api concurrency of two. \n\nFor this cluster, Initial data ingress, or other bulk data ingress, should be done using Bulk API due to its efficiency and its isolated connection queues. \n\nBatch sizes should be determined experimentally based on your document size, we recommend shooting for approximately one second of request duration. If requests are slower than one-second, reduce your batch size. If requests are consistently faster than one-second, add more documents to your batch size until it hovers right around a one-second average.\n\nA concurrency level of two usually translates to 2–4 background workers sending in updates, depending on the latency and overhead involved in fetching and serializing documents from the primary database.","excerpt":"","slug":"connection-management","type":"basic","title":"Optimizing Your Requests"}

Optimizing Your Requests


Bonsai implements connection management as a metered plan resource. Our connection management is designed to help model and encourage best practices for using Elasticsearch efficiently at different cluster sizes. [block:api-header] { "type": "basic", "title": "Read, Write & Bulk Requests" } [/block] Requests are categorized into three groups, based on the HTTP method and sometimes the path. The first group is read requests, including `HEAD`, `GET`, `OPTIONS` and `POST`s to `_search` and related search endpoints. The second group is for Bulk API requests: any request to a `_bulk` endpoint. Finally, all other write requests. It's worth noting that Bulk API updates are grouped separately from other writes. This is because the use of the Bulk API is encouraged as the more efficient means of data ingress into Elasticsearch. Other single-document updates are helpful for maintaining synchronization over time with your primary database, but should be avoided as a means for mass ingress of data. [block:callout] { "type": "info", "title": "ProTip: Use a Queue", "body": "For best performance and reliability, we recommend that most updates be stored in a durable message queue for asynchronous grouping and processing in batches. Consider message queues such as Apache Kafka, AWS Kinesis, IronMQ, Disque, Redis, RabbitMQ, and so on." } [/block] [block:api-header] { "type": "basic", "title": "Measuring Concurrency" } [/block] Concurrency limits are measured in terms of active requests in-flight to Elasticsearch. An otherwise idle HTTP keep-alive connection is not tracked toward this limit; we encourage you to maintain a reasonably sized pool of keep-alive connections to reduce the setup cost of each connection and speed up your average request. When the number of in-flight requests exceeds the cluster's concurrency limit, we queue incoming requests and serve them on a first-come-first-served basis. This queue is a best-effort mechanic on our end, intended to smooth out fluctuation and protect Elasticsearch from becoming overloaded when a cluster's traffic is operating near its connection limits. It is not a durable message queue, nor does it replace client-side queueing for updates. [block:api-header] { "type": "basic", "title": "Optimizing Bulk Api Usage" } [/block] For example, consider a cluster on a plan that offers bulk api concurrency of two. For this cluster, Initial data ingress, or other bulk data ingress, should be done using Bulk API due to its efficiency and its isolated connection queues. Batch sizes should be determined experimentally based on your document size, we recommend shooting for approximately one second of request duration. If requests are slower than one-second, reduce your batch size. If requests are consistently faster than one-second, add more documents to your batch size until it hovers right around a one-second average. A concurrency level of two usually translates to 2–4 background workers sending in updates, depending on the latency and overhead involved in fetching and serializing documents from the primary database.