1. 首頁
  2. 問答
  3. 減少往返服務器/數據庫

減少往返服務器/數據庫

2009-07-12 95 views
3

在編寫ASP.NET頁面時，您會發現您的頁面正在向數據庫或服務器進行太多往返操作？減少往返服務器/數據庫

（這是一個普遍的問題，但我說ASP.NET是我的大部分編碼是在網頁上的東西）。

來源

2009-07-12 dotnetdev

+0

https://blogs.msdn.microsoft.com/jjameson/2010/09/03/analyzing-database-roundtrips-with-sql-server-profiler/ 和 https://msdn.microsoft.com/ en-us/library/5dws599a（v = vs.71）.aspx – 2017-05-10 15:37:55

回答

4

多少太多了？ 100萬歐元的問題！簡介。然後輪廓。如果您的應用程序花費大部分時間進行數據訪問，則會出現問題（並且應該查看sql跟蹤）。如果它花費大部分時間來繪製UI，那麼（假設您的視圖沒有進行數據訪問），您應該先查看其他地方...

來源

2009-07-12 23:12:26

+1

Web服務器不會繪製UI，但我猜測生成的HTML是等價的。儘管如此，問題並不在於服務器花費多少時間，而在於等待並等待多久。 – 2009-07-12 23:43:31

1

往返延遲與總數據量被移動，所以它對於優化它們確實有意義。通常的方法是使用執行多個步驟的存儲過程，甚至可能返回多個結果集。

來源

2009-07-12 23:42:04

0

我知道這聽起來有點反覆，但客戶端服務器往返取決於連接的任何一側有多少程序邏輯。

首先要檢查的是驗證：您必須始終在服務器端驗證和消毒您的輸入，但這並不意味着您在客戶端也不能這樣做，從而減少僅用於檢查的往返行程輸入。

第二：在客戶端可以做些什麼來減少服務器端過載？有些計算可以在客戶端查看或製作。還有AJAX可以用來只加載正在改變的頁面的一部分。

第三：你可以委託工作到另一臺服務器嗎？如果您的服務器負載過重，爲什麼不使用Web服務或將邏輯的某個方面委託給另一個服務器？

As Mark寫道：¿太多了？這取決於你和你的預算。

來源

2009-07-13 00:11:24 backslash17

0

當編寫ASP.NET頁面，標誌是什麼 你尋找你的頁面 拍過多往返於 數據庫或服務器？

當然，這一切都取決於你，你必須配置文件。但是，這裏有一些指標，但並不意味着有一個問題，但往往會顯示

  • 頁花費很長的時間來本地呈現。

  • 要渲染你需要超過30個往返的頁面。我把這個數字從我的帽子裏拿出來，但假設往返時間大約爲3.5ms，那麼在任何其他類型的處理之前，30次往返將超過100ms指南。

  • 渲染頁面所涉及的所有查詢都進行了大量優化，並且不超過一個毫秒或兩個時間段才能執行。不需要每次渲染頁面時都執行大量CPU週期的操作。

  • 數據訪問被抽象掉而不是以任何方式緩存。例如，如果GetCustomer將調用DAL，然後發出查詢，並且您的頁面要求提供100個未成批檢索的Customer對象，則可能會遇到問題。

來源

2009-07-13 01:37:14

1

我所做的是我看看ASP性能計數器和SQL性能計數器。爲了獲得準確的度量，您必須確保SQL Server上沒有隨機噪聲活動（即與網站無關的導入批處理）。

相關的計數器我看是：

  • SQL Statistics/Batch requests/sec：這表明服務器到底有多少的Transact-SQL批處理接收。在大多數情況下，它可以等於1：1與從網站到SQL的往返次數。
  • Databases/Transaction/sec：該計數器是針對每個數據庫實例化的，所以我可以快速看到哪個數據庫中存在「活動」。這樣我可以關聯網站數據往返（即我的應用程序邏輯請求，去應用程序數據庫）和ASP會話狀態和用戶的東西（去Asp會話數據庫或tempdb）
  • Databases/Write Transaction/sec：這我關聯上面的計數器（每秒交易次數），所以我可以感受到網站正在進行的讀寫比率。
  • ​​：有了這個計數器，我可以得到網站看到的請求數/秒。與SQL批處理請求數/秒相關，它可以很好地指示每個請求的往返次數。

接下來要衡量的內容通常是試着去感受一下在請求中花費的時間。在我自己的項目中，我大量使用performance counters I publish myself，所以很容易測量。但我並不總是那麼幸運，只能清理我自己的爛攤子......分析通常對我來說不是一種選擇，因爲我大部分時間都對我無法測試的現場生產系統進行故障排除。

我的方法是首先嚐試理清事物的SQL方面，因爲在SQL中很容易找到執行時間的相關統計信息：SQL保留了一個很好的彙總統計信息，可以在sys.dm_exec_query_stats中查看。我也可以使用Profiler來實時測量執行持續時間。通過對收集的這些數據進行一些分析，瞭解訪問量最大的頁面的正常請求模式，您可以很好地估計每個Web請求在SQL中花費的總時間。如果這個時間幾乎加起來就需要請求服務頁面，那麼你就有了答案。

並回答最初的問題標題：減少往返次數，您減少請求。認真。首先，緩存什麼是適當的緩存我想是顯而易見的。其次，您可以降低複雜性：不要在每個頁面上顯示不必要的數據，當您可以避開它時緩存並顯示陳舊的數據，您會隱藏次要導航面板上的詳細信息。

如果您覺得問題是往返次數本身而不是請求次數（即，您將從一次往返中分批多次請求中獲得巨大收益），那麼您應該以某種方式衡量往返的開銷是什麼殺了你。通過正常網絡連接建立連接池通常不是最重要的因素。

最後，你應該看看是否所有可以在組中完成的事情都是以組爲單位完成的。如果你有一些半角的ORM從一個ID鍵集中一次一個地檢索對象，那就去掉它。

來源

2009-07-17 23:37:58

相關問題

 相關問題