IIS大資料請求設定方法

標籤：

大並發大資料量請求一般會分為幾種情況：

1.大量的使用者同時對系統的不同功能頁面進行尋找，更新操作

2.大量的使用者同時對系統的同一個頁面，同一個表的大資料量進行查詢操作

3.大量的使用者同時對系統的同一個頁面，同一個表進行更新操作

 

對於第一種情況一般處理方法如下：

一。對伺服器層面的處理

1. 調整IIS 7應用程式集區隊列長度

由原來的預設1000改為65535。

IIS Manager > ApplicationPools > Advanced Settings

Queue Length : 65535

2.  調整IIS 7的appConcurrentRequestLimit設定

由原來的預設5000改為100000。

c:\windows\system32\inetsrv\appcmd.exe set config /section:serverRuntime /appConcurrentRequestLimit:100000

在%systemroot%\System32\inetsrv\config\applicationHost.config中可以查看到該設定：

<serverRuntime appConcurrentRequestLimit="100000" />  

 

3. 調整machine.config中的processModel>requestQueueLimit的設定

由原來的預設5000改為100000。

1. <configuration>  
2.     <system.web>
3.         <processModel requestQueueLimit="100000"/>   

4. 修改註冊表，調整IIS 7支援的同時TCPIP串連數

由原來的預設5000改為100000。

reg add HKLM\System\CurrentControlSet\Services\HTTP\Parameteris /v MaxConnections /t REG_DWORD /d 100000 

完成上述4個設定，就基本可以支援10萬個同時請求。如果訪問量達到10萬以上，就可以考慮將程式和資料庫按功能模組劃分部署到多個伺服器分擔訪問壓力。另外可以考慮軟硬體負載平衡。硬體負載平衡能夠直接通過智能交換器實現，處理能力強，而且與系統無關，但是價格貴,配置困難，不能區分實習系統與應狀態。所以硬體負載平衡適用於一大堆裝置，大訪問量，簡單應用。軟體負載平衡是基於系統與應用的，能過更好地根據系統與應用的狀況來分配負載。性價比高。PCL負載平衡軟體，Linux下的LVS軟體。

 

二。對資料庫層面的處理

      當兩個使用者同時訪問一個頁面，一個使用者可能更新的是另一個使用者已經刪除的記錄。或者，在一個使用者載入頁面跟他點擊刪除按鈕之間的時間裡，另一個使用者修改了這條記錄的內容。所以需要考慮資料庫鎖的問題

有下面三中並發控制策略可供選擇：

Ø 什麼都不做 –如果並發使用者修改的是同一條記錄，讓最後提交的結果生效（預設的行為）

Ø 開放式並發（Optimistic Concurrency） - 假定並發衝突只是偶爾發生，絕大多數的時候並不會出現； 那麼，當發生一個衝突時，僅僅簡單的告知使用者，他所作的更改不能儲存，因為別的使用者已經修改了同一條記錄

Ø 保守式並發（Pessimistic Concurrency） – 假定並發衝突經常發生，並且使用者不能容忍被告知自己的修改不能儲存是由於別人的並發行為；那麼，當一個使用者開始編輯一條記錄，鎖定該記錄，從而防止其他使用者編輯或刪除該記錄，直到他完成並提交自己的更改

當多個使用者試圖同時修改資料時，需要建立控制機制來防止一個使用者的修改對同時操作的其他使用者所作的修改產生不利的影響。處理這種情況的系統叫做“並發控制”。

並發控制的類型

通常，管理資料庫中的並發有三種常見的方法：

• 保守式並發控制 - 在從擷取記錄直到記錄在資料庫中更新的這段時間內，該行對使用者不可用。
• 開放式並發控制 - 只有當實際更新資料時，該行才對其他使用者不可用。更新將在資料庫中檢查該行並確定是否進行了任何更改。如果試圖更新已更改的記錄，則將導致並發衝突。
• 最後的更新生效 - 只有當實際更新資料時，該行才對其他使用者不可用。但是，不會將更新與初始記錄進行比較；而只是寫出記錄，這可能就改寫了自上次重新整理記錄後其他使用者所進行的更改。

保守式並發

保守式並發通常用於兩個目的。第一，在某些情況下，存在對相同記錄的大量爭用。在資料上放置鎖所費的成本小於發生並發衝突時復原更改所費的成本。

在事務過程中不宜更改記錄的情況下，保守式並發也非常有用。庫存應用程式便是一個很好的樣本。假定有一個公司代表正在為一名潛在的客戶檢查庫存。您通常要鎖定記錄，直到產生訂單為止，這通常會將該項標記為“已訂購”狀態並將其從可用庫存中移除。如果未產生訂單，則將釋放該鎖，以便其他檢查庫存的使用者得到準確的可用庫存計數。

但是，在斷開的結構中無法進行保守式並發控制。串連開啟的時間只夠讀取資料或更新資料，因此不能長時間地保持鎖。此外，長時間保留鎖的應用程式將無法進行伸縮。

開放式並發

在開放式並發中，只有在訪問資料庫時才設定並保持鎖。這些鎖將防止其他使用者在同一時間更新記錄。除了進行更新這一確切的時刻之外，資料始終可用。有關更多資訊，請參見開放式並發。

當試圖更新時，已更改行的初始版本將與資料庫中的現有行進行比較。如果兩者不同，更新將失敗，並引發並發錯誤。這時，將由您使用所建立的商務邏輯來協調這兩行。

最後的更新生效

當使用“最後的更新生效”時，不會對初始資料進行檢查，而只是將更新寫入資料庫。很明顯，可能會發生以下情況：

• 使用者 A 從資料庫擷取一項記錄。
• 使用者 B 從資料庫擷取相同的記錄，對其進行修改，然後將更新後的記錄寫回資料庫。
• 使用者 A 修改“舊”記錄並將其寫回資料庫。

在上述情況中，使用者 A 永遠也不會看到使用者 B 作出的更改。如果您計劃使用並發控制的“最後的更新生效”方法，則要確保這種情況是可以接受的。

ADO.NET 和 Visual Studio .NET 中的並發控制

因為資料結構基於斷開的資料，所以 ADO.NET 和 Visual Studio .NET 使用開放式並發。因此，您需要添加商務邏輯，以利用開放式並發解決問題。

如果您選擇使用開放式並發，則可以通過兩種常規的方法來確定是否已發生更改：版本方法（實際版本號碼或日期時間戳記）和儲存所有值方法。

版本號碼方法

在版本號碼方法中，要更新的記錄必須具有一個包含日期時間戳記或版本號碼的列。當讀取該記錄時，日期時間戳記或版本號碼將儲存在用戶端。然後，將對該值進行部分更新。

處理並發的一種方法是僅當 WHERE 子句中的值與記錄上的值匹配時才進行更新。該方法的 SQL 表示形式為：

UPDATE Table1 SET Column1 = @newvalue1, Column2 = @newvalue2WHERE DateTimeStamp = @origDateTimeStamp

或者，可以使用版本號碼進行比較：

UPDATE Table1 SET Column1 = @newvalue1, Column2 = @newvalue2WHERE RowVersion = @origRowVersionValue

如果日期時間戳記或版本號碼匹配，則表明資料存放區區中的記錄未被更改，並且可以安全地使用資料集中的新值對該記錄進行更新。如果不匹配，則將返回錯誤。您可以編寫代碼，在 Visual Studio .NET 中實現這種形式的並發檢查。您還必須編寫代碼來響應任何更新衝突。為了確保日期時間戳記或版本號碼的準確性，您需要在表上設定觸發器，以便在發生對行的更改時，對日期時間戳記或版本號碼進行更新。

儲存所有值方法

使用日期時間戳記或版本號碼的替代方法是在讀取記錄時擷取所有欄位的副本。ADO.NET 中的 DataSet 對象維護每個修改記錄的兩個版本：初始版本（最初從資料來源中讀取的版本）和修改版本（表示使用者更新）。當試圖將記錄寫回資料來源時，資料行中的初始值將與資料來源中的記錄進行比較。如果它們匹配，則表明資料庫記錄在被讀取後尚未經過更改。在這種情況下，資料集中已更改的值將成功地寫入資料庫。

對於資料配接器的四個命令（DELETE、INSERT、SELECT 和 UPDATE）來說，每個命令都有一個參數集合。每個命令都有用於初始值和當前值（或修改值）的參數。

 

 

對於第二種情況的處理：

因為是大並發請求，也能採用第一種情況的處理方法，另外因為是對大資料量進行檢索，所以需要考慮查詢效率的問題

1.對錶按查詢條件建立索引

2.對查詢語句進行最佳化

3.可以考慮對查詢資料使用緩衝

 

對於第三種情況的處理：

也能採用第一種情況的處理方法，另外因為是對同一個表進行更新操作，可以考慮使用下面的處理方法：

1.先將資料儲存到緩衝中，當資料達到一定的數量後，再更新到資料庫中

2.將表按索引劃分(分表，分區)，如：對於一個儲存全國人民資訊的表，這個資料量是很大的，如果按省劃分為多個表，在將全國的人民資訊按省儲存到相應的表中，然後根據省份對相應的並進行查詢和更新，這樣大並發和大資料量的問題就會減小很多

本文系轉寄，未驗證，等有空了測試一下

IIS大資料請求設定方法