solr中有兩類主要的請求處理器：
處理查詢請求的搜尋處理器（searchhander）
處理索引請求的更新處理器（updatehander）
通常情況下，乙個搜尋處理器由以下元件組成，其中每個元件都定義在solrconfig.xml檔案中。
預處理元件（first-components）—— 一組優先執行的可選搜尋元件，執行預處理任務。
主搜尋元件（components）—— 一組鏈式組合的搜尋元件，至少包含查詢元件。
後處理元件（last components）—— 一組可選的鏈式組合的搜尋元件，執行後處理任務。
solr的query performance和searcher搜尋器密切相關。
1024
-1true
true
true
true
20200
static firstsearcher warming in solrconfig.xml
false
4
slowquerythresholdmillis
filtercache
queryresultcache
documentcache
cache
fieldvaluecache
enablelazyfieldloading
usedocvaluegetfield
sortdocidbeforegetdoc
usefilterforsortedquery
queryresultwindowsize
queryresultmaxdocscached
listener event=「newsearcher」 class="solr.querysenderlistener"
listener event=「firstsearcher」 class="solr.querysenderlistener"
usecoldsearcher
適用於乙個搜尋請求已經被提交，而目前solr中沒有定義搜尋器的情形。
如果該值為false，那麼solr將會一直處於阻塞狀態，知道正在預熱的搜尋器執行完索引的預熱查詢。
以田徑賽場為例，false意味著指令官等到運動員充分熱身之後才發出開始指令，不管這需要等多久。
如果該值為true，則solr會立即使乙個正在預熱的搜尋器進入活躍狀態，而不管搜尋器的預熱程度如何。
如果該值為true，則意味著比賽馬上就要開始，不管運動員是否已經熱身充分了。
maxwarmingsearchers
該元素允許開發者控制後台併發預熱的搜尋器的最大數目。
一旦達到閾值，新的提交請求將會失敗。
這是一種很好的保障機制，因為後台並預熱的搜尋器過多時會快速耗盡伺服器的記憶體和cpu資源。
透過表象看本質！？
做了這麼多年學生，一直不知道該如何搞科研。直到有一天，我在興致勃勃的調 調整著引數，看著結果。就在這時，導師也蠻有興致的走過看，並發問，這結果說明了什麼？為什麼不能？那什麼方法能？這些方法有什麼異同？導師連珠炮式問了下去。留下傻傻的我在一邊，我還沒調研過。那就去調研一下，只是這樣的看是不能幫你解決你...
透過表象看本質
前段時間，好友王胖子問了熊熊乙個問題，他們的 oracle 資料庫，有個主要的表空間設定的自動增長，每次增長 100m 卻無法滿足業務需求，問了一下 oracle 方面，說是自動增長的步長太小了，於是胖子在資料庫裡查詢了一下，有了以下的問題 胖子 熊，在麼，問個問題？熊熊 啥問題 胖子 看看，我這個...
透過現象看本質
例子 你回家的時候，發現沒帶鑰匙，你聯絡了乙個鎖匠來開鎖，結果他很快來了，並且在一分鐘之內給你開啟了鎖，問你要1000元，你會覺得很不值 但是如果乙個鎖匠用了幾個小時或者更長時間幫你開啟了鎖，你會看到他的努力，要同樣的錢，你會覺得很合理 這實際上是乙個誤區，人往往會看到一些表面的努力，而忽略了一些隱...