投影同步數據庫查詢

Question

我想了解人們如何計算數據庫負載以用於容量規劃。我沒有把它放在服務器故障上，因爲這個問題與測量應用程序而不是定義基礎設施有關。在這種情況下，擔心這個問題是別人的工作！

我知道有一個巨大的變量數在這裏，但我感興趣的是別人如何去獲得數量級的粗糙秩序感。在創建任何特定設計之前，這只是項目生命週期早期的成本計算練習，因此在此階段沒有大量信息要繼續。

我從基礎設施人員提出的問題是「同時有多少用戶」。我們不要辯論只尋求這一個數字的理由;這正是在這種情況下所要求的！

這是一個web前端，SQL Server和一個相當固定的，容易量化的觀衆後端。釘下來到一個非常粗略的方式實際的併發請求，我看到它的方式，把它歸結爲測量的越來越精細單位：

1. 總觀衆
2. 併發會話
3. 同時請求
4. 同時DB查詢

此不考慮因素，如Web應用程序緩存，局部頁面請求，記錄容量等，並有以DEFI需要一些創意牌每個用戶的請求頻率以及數據庫命中和執行時間的數量，但這似乎是一個合理的起點。我也意識到需要調整峯值負載，但如果需要，這可以插入同時進行的會話中。

這是無可否認的非常基本，我敢肯定，那裏有更全面的指導。如果任何人都可以分享他們對這個練習的方法，或者將我指向其他資源，這可能會使這個過程變得更加特別，那會很棒！

Answer 1

我會嘗試，但顯然不知道細節，很難給出精確的建議。

首先，基礎設施球員可能會要求從許可的觀點來看這個問題（SQL服務器可以按用戶或CPU許可）

現在回到你的問題。如果你能預測/計算出這個數字，那麼「總觀衆數」就很重要。當所有用戶同時訪問數據庫時（例如，每個人登錄時上午9點），這可能會導致最糟糕的情況。

如果您存儲會話信息，你可能會爲每位用戶設置（1個會話+ 1主DB）至少2個連接。但是這個數字可以（有時候明顯地）被連接池減少（取決於你如何連接到數據庫）。 使用最壞的情況 - 50個系統連接+ 2 *個用戶數量。

同時請求/查詢取決於應用程序的性質。需要更多細節。 更多的同時請求（到您的前端）不一定會轉化爲後端的更多請求。

說了這麼多 - 爲了成本目的，您需要關注更大的圖片。

1. SQL服務器許可證（如果我的記憶服務我的話）將花費約128K AUD（雙Xeon）。熱/熱備用？成本加倍。

2. 磁盤存儲 - 您需要多少存儲空間？磁盤相對便宜，但如果您要使用SAN，成本可能會變得明顯。另外 - 從性能角度來看，磁盤越多越好。