1.使用塊查詢
塊查詢一般來說比單文檔查詢表現出更好的性能。爲了獲取快查詢最佳新能，你可以在單節點地單分片上運行一個基準，第一次100個文檔，第二次200個文檔，然後400個，以此類推。每次基準運行的數量都是兩倍於前一次的數量。當索引速度達到峯值的時候你就知道你的數據索引最佳的塊文檔數量。如果峯值存在於兩個數量上，最好還是以最少的數量去索引。塊查詢數量越大也就意味着在進行同步查詢的時候對內存壓力也就越大。建議大家每次發送請求時不要超過幾十兆儘管有時更大的請求表現地更好。
2.使用多線程發送數據到es中
使用單個線程不可能將es集羣的索引性能最大化。爲了充分利用es集羣的資源，你應該使用多線程或進程發送數據。除了最大化集羣的資源使用，這也會幫助減少非同步的成本。
注意TOO_MANY_REQUESTS(429)返回碼（在java客戶端中報EsRejectedExecutionException錯誤），這是告訴你es目前無法跟上你的索引速率。當這種情況發生時，你應該在下次發送請求之前先暫停下。理想情況下，它會自動恢復。
跟確定最佳bulk請求數量類似，只有通過測試才能知道最佳的調用者數量是多少。這可以通過增加調用者數量來測試並在I/O或CPU飽和的情況下得到結果
3.提高刷新間隔
默認情況下，index.refresh_interval是1s，意味着es會每秒創建一個新的分片，但是你可以通過增加這個值（例如30s）來增大在每個刷新間隔中創建更多的分片並能夠減少未來合併的壓力
4.在進行初始加載的時候禁用索引刷新和索引複製
如果你要一次性進行大量的數據加載操作，你應該通過設置index.refresh_interval爲-1並設置index.number_of_replicas爲0.這會讓你的索引暫時處於危險之中，因爲丟失任何分片都會使數據丟失，但是同時也會導致索引更快因爲文檔只會被索引一次。一旦初始化加載結束，應該把上面兩個參數設置爲原來的值
5.禁用交換機制
確保操作系統不會因爲禁用交換機制來交換java進程
6.給文件系統緩存留有足夠的內存空間
文件系統的緩存會被使用到因爲需要緩衝I/O操作。你應當確保運行es的機器還有一般的內存留給文件系統用作緩存
7.使用自動生成的ids
當索引一個有具體id的文檔時，es需要檢查同一分片中是否存在匹配到該id的文檔，這會花費很多時間並且在id越大的時候成本越高。通過使用自動生成的id，es會調過這些檢查，這將會使得索引變得更加快速
8.使用更快的硬件
如果索引速度被I/O制約，你需要提供爲文件系統緩存提供更多的內存或者升級更快的硬件設備了。一般固態比機械硬盤性能更好。始終使用本地文件系統，遠程文件系統像NFS以及SMB都應該避免。對例如亞馬遜的EBS(elastic block storage)也要留意，es在虛擬存儲上表現更好，由於更快以及易於安裝使得它變得越來越受歡迎。但是不幸的是相比於本地存儲虛擬存儲還是有一些差距。如果你要使用EBS請注意要使用提供的IOPS否則會被限流
通過配置RAID爲一個空數組，可以讓索引分配在多個SSD上，但是要注意它會增加故障風向因爲任意一個SSD故障都會導致索引損壞。然而這通常是一個正確的做法：優化單個分片以獲得最大性能，並且在不同的節點上添加副本分片以提高可用性。你也可以使用snapshot和restore備份索引來獲得進一步的保險
9.索引緩衝區大小
如果你的節點只做高負荷的索引，確保indices.memory.index_buffer_size大到足以爲每個分片提供最多512MB的索引緩衝區進行大量索引(超過512MB索引性能也不會得到顯著的提升)。es會採用這個配置(java堆的百分比或者絕對值)，然後使用它在所有活躍的分片中作爲公用緩衝區。非常活躍的分片自然會使用更多的緩衝區空間而那些輕量級查詢的分片用得更少。
默認10%足夠了，例如：如果你給JVM10G的內存，它會給索引緩存區1G，這將對於兩個高負荷分片提供足夠的內存空間。
10.禁用_field_names
_field_names字段會帶來額外的索引開銷，所以如果你不用運行esists查詢就可以禁用它