-
autoConnectRetry僅僅意味着驅動程序會自動嘗試重新連接到意外斷開連接后在服務器（一個或多個）。在生產環境中，您通常需要將此設置為true。
-
connectionsPerHost是物理連接的單一實例蒙戈（它的單，所以你通常每個應用程序的話）能夠建立到的mongod/mongos處理量。在撰寫本文時，即使實際查詢吞吐量較低，Java驅動程序也會建立這種連接數量（換句話說，您將看到mongostat中的“conn”統計值上升，直到它達到每個應用程序服務器的這個數量）。
在大多數情況下，沒有必要將此設置為高於100，但此設置是其中一項“測試並看到”的內容。請注意，您必須確保您設置足夠的這種低使連接到您服務器的總量不超過
db.serverStatus().connections.available在生產我們目前有這個在40
-
connectTimeout。由於名稱表示毫秒數，驅動程序將在連接嘗試中止之前等待。設置超時時間（15-30秒），除非有一個現實的，預期的機會，這將成為其他成功的連接嘗試。通常，如果連接嘗試時間超過幾秒，則網絡基礎結構無法實現高吞吐量。
-
maxWaitTime。線程等待連接池上可用連接的數量，如果不及時發生，則會引發異常。保持默認。
-
了socketTimeout。標准套接字超時值。設置為60秒（60000）。
-
threadsAllowedToBlockForConnectionMultiplier。 connectionsPerHost的倍數，表示如果池當前耗盡，允許等待連接變為可用的線程數。這是會導致“com.mongodb.DBPortPool $ SemaphoresOut：Out of semaphores獲取db連接”異常的設置。一旦此線程隊列超過threadsAllowedToBlockForConnectionMultiplier值，它將拋出此異常。例如，如果connectionsPerHost為10，並且此值為5，則在拋出上述異常之前，最多可有50個線程阻塞。
如果你希望在吞吐量大的峰值，可能會導致大隊列暫時增加該值。正因為這個原因，我們目前在1500點。如果您的查詢負載一直超過服務器，那么您應該相應地改善硬件/擴展情況。
-
readPreference。 （更新2.8+）用於確定默認讀取偏好和替換“slaveOk”。通過一種類工廠方法設置ReadPreference。 最常見設置的完整描述可以在這個帖子
-
W¯¯的末尾。 （更新，2.6+）該值確定寫入的“安全性”。當此值為-1時，無論網絡或數據庫錯誤如何，寫入都不會報告任何錯誤。 WriteConcern.NONE是適合此預定義的WriteConcern。如果w是0，那么網絡錯誤將使寫入失敗，但mongo錯誤不會。這通常被稱為“火災和遺忘”寫入，並應在性能比一致性和耐久性更重要時使用。為此模式使用WriteConcern.NORMAL。
如果把W為1或更高的寫入被認為是安全的。安全寫入執行寫入操作，然后通過向服務器發送請求進行跟蹤，以確保寫入成功或檢索到錯誤值（如果沒有寫入）（換言之，寫入后發送getLastError（）命令）。請注意，在此getLastError（）命令完成之前，連接被保留。作為其中的一個結果和附加命令的吞吐量將signficantly低於以w < = 0。1完全相同的MongoDB的W值保證寫入成功（或失敗核查的），你發送的寫入實例寫道。
在副本集的情況下，您可以使用更高的值來告訴MongoDB在返回之前將寫入發送到副本集的至少“w”個成員（或更准確地說，等待寫入的復制“w”成員）。您還可以將w設置為字符串“majority”，它告訴MongoDB執行寫入大部分副本集成員（WriteConcern.MAJORITY）的操作。通常，您應該將其設置為1，除非您需要原始性能（-1或0）或復制寫入（> 1）。高於1的值對寫入吞吐量有相當大的影響。
-
FSYNC。強制mongo在啟用每次寫入后刷新到磁盤的耐久性選項。我從來沒有遇到與寫入積壓相關的任何持久性問題，所以我們在生產中使用了這個錯誤（缺省值）。
-
j * （NEW 2.7+） *。布爾值，當設置為true時，會強制MongoDB在返回之前等待成功的日記組提交。如果您啟用了日記功能，則可以啟用此功能以獲得更多耐用性。請參閱http://www.mongodb.org/display/DOCS/Journaling以查看日志可以獲取什么內容（以及為什么您可能需要啟用此標志）。
ReadPreference 的ReadPreference類允許您配置什么的mongod，如果你是副本集工作查詢路由實例。下列選項：
-
ReadPreference.primary（）：所有讀取到只有repset主要成員。如果您要求所有查詢返回一致的（最近寫入的）數據，請使用此選項。這是默認設置。
-
ReadPreference.primaryPreferred（）：如果可能，所有讀取轉到repset主成員，但可以查詢次要成員，如果主節點不可用。因此，如果主服務器變得不可用，則讀取變為最終一致，但只有當主服務器不可用時。
-
ReadPreference.secondary（）：所有讀取轉到次級repset成員，主要成員僅用於寫入。只有在最終一致讀取的情況下才能使用它。額外的repset成員可用於擴展閱讀性能，盡管repset可能有（投票）成員的數量有限制。
-
ReadPreference.secondaryPreferred（）：如果其中任何一個可用，所有讀取都轉到次級repset成員。主要成員專門用於寫入，除非所有次要成員都不可用。除了用於讀取的主要成員回退以外，它與ReadPreference.secondary（）相同。
-
ReadPreference.nearest（）：讀取轉到可用於數據庫客戶端的最近的repset成員。僅在最終一致性讀取可接受時才使用。最近的成員是客戶端和各種repset成員之間延遲最低的成員。由於忙碌的成員最終會有更高的延遲，這個應該也會自動平衡讀取負載，盡管在我的經驗中，如果成員延遲相對一致，secondary（Preferred）看起來會更好。
-