IIS 7真的很慢並行C＃字符串

我們有一個大型系統已經實現了很多字符串連接 - 它無處不在。IIS 7真的很慢並行C＃字符串

我們寫了一個快速頁面，在一個循環中連接字符串。這在我們的dev boxen（調試關閉）和我們的測試虛擬機上運行3.3s。然而，在生產（IIS7）它運行在15.7s。

任何人都可以建議我們可以看看服務器端（IIS設置，內存設置等）來解決這個問題嗎？

供參考 - 服務器有大量的可用內存和空閒的CPU週期 - 所以它不是一個資源問題。 重寫所有使用string.Join或StringBuilder的代碼不在預算中。

來源

2012-11-27 Jack

如何連接字符串，+或使用StringBuilder類？ –

Sergey - 本質上是sStringMain + = sStringSub; – Jack

你能展示更可行的代碼，我們可以看到你在做什麼，反對我們不得不猜測或玩心理讀者..？ – MethodMan

這會在內存中創建大量細小的字符串對象，這些對象需要稍後由垃圾收集器收集。將其替換爲

var sMain = new StringBuilder(); 
    while (something) 
    { 
    sMain.Append(sStringSub); 
    // ... 
    } 

    // Call sMain.ToString() when you need the whole string

來源

2012-11-27 00:18:07

正如我所說，這個選項不在預算之內，它不能解釋差異 - 請在發佈答案前閱讀問題。 – Jack

我會預先分配StringBuilder更多的內存。默認情況下它保存16個字符。一旦它需要爲更大的數據重新分配一塊新的內存，它實際上會影響性能。 –

@SimonWhitehead這不是.NET中StringBuilder的工作方式。與List類似，可以擴展StringBuilder而不必將舊內容複製到新數組中。否則StringBuilder將是無用的。我個人嘗試設置StringBuilder的創建能力，如果我有一個大致的想法應該是多大，但這是一個微觀的性能優化，這是不可檢測的。 – Trisped

將您開發箱上的網站設置與您的生產箱相區別。有很多事情可能會導致不同，從工作者線程數到最大內存大小。如果跨越這些閾值，IIS將回收該工作人員。

另外，你在開發盒上使用IIS或Cassini？

檢查您的應用程序未在調試模式下運行。

來源

2012-11-27 00:28:50 Heather

不能相信我是第一個推薦RedGates Profiling Tools。

這將告訴你到底是什麼花了這麼多時間在服務器與開發PC上。

字符串是存儲在託管堆上的引用類型，因此受垃圾回收處理。 GC將在第一次GC檢測到它無法釋放內存時將字符串向上推進（0,1,2）。如果你看一下CLR Profiler我敢打賭，你會看到一個字符串噸分配給代2.

重寫全部代碼使用的string.join或StringBuilder的不是預算。

不管它是否在預算內。如果一個應用程序需要15秒的響應時間，沒有人會想要使用它，你不會賺錢。你將不得不改變一些東西。

沒有探查器跟蹤它在黑暗中拍攝一樣...我最好的猜測是開發PC有SSD。

即使字符串是不可變的，並且大部分內存可能指的是已經連接的GC無法收集的字符串。我仍然不認爲這是一個記憶問題，我敢打賭，它與I/O有關，但探查器的痕跡將證實。

來源

2012-11-27 01:36:54

IIS 7真的很慢並行C＃字符串

回答

相關問題