誰能向我解釋一下，為什么在一個pod上運行我的負載測驗時，它的TPS比擴展到兩個pod時更好。 我預計，在2個豆莢上以相同的配置調整相同的場景時，TPS會增加，但事實并非如此。
- 這是否是正常的行為，即橫向擴展不會提高請求的總數？ 請注意，我在O e pod上沒有得到任何故障，只是擴展到2個以獲得高可用性
uj5u.com熱心網友回復：
如果你正在使用任何型別的資料庫，這是一個需要優化以提高TPS的地方。原因如下：
假設你的資料庫是在一個很短的時間內完成的。
假設你的資料庫運行得盡可能快--pod可以處理網路連接并對資料庫進行查詢，但是資料庫很慢，因為CPU/記憶體/TPS已經達到上限；增加pod 1的TPS量不會增加你的TPS，因為資料庫TPS是限制因素。
現在，如果您添加 pod 2，您的 DB 仍然擁有最大的 CPU/記憶體/TPS，但現在它必須使用之前使用的一些 CPU 來完成交易，以管理來自 pod 2 的 DB 連接，這些連接必須排隊等待 DB 的 CPU/記憶體能夠處理它們；最終降低 DB 的 TPS 和整個應用程式的 TPS。
簡而言之：如果您的 DB 已達到最大值，添加 pod 以對其進行交易將降低 TPS，因為 DB 必須使用原本積極處理交易（您的 TPS 限制因素）的資源來處理排隊的 DB 連接。
要解決這個問題，請縱向擴展您的寫資料庫，橫向擴展您的讀資料庫，用索引或更好的查詢來優化資料庫事務，使用 PGBouncer 來管理資料庫連接，并確保您的資料庫事務型別對您的使用情況而言是最有效的。
uj5u.com熱心網友回復：
這真的取決于你的pod做了什么。 正如@spencer所提到的。除此之外，還有很多因素會影響你的期望：
基于你的情況，我猜你的pod不是限制TPS的因素。
基本來說，增加pod的復制至少不會降低TPS。
uj5u.com熱心網友回復：
... my load test on one pod it gives 更好的 TPS 反而 比 when scaling to two pods。
當2個pod爭奪同一資源并造成瓶頸時，就會發生這種情況。
Is this normal behaviour that scalinghorizontal not improve the total number of requests?
客戶端（網路）請求可以提高，但后臺的能力，有時也包括中間件（如果有的話），需要跟上。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/319490.html
標籤：