0

多くの文字列連結で実装された大規模なシステムがあります-それはどこにでもあります。

文字列をループで連結するクイックページを作成しました。これは、開発ボックス（デバッグオフ）とテストVMで3.3秒で実行されます。ただし、本番環境（IIS7）では、15.7秒で実行されます。

これを説明するためにサーバー側で何を見ることができるか（IIS設定、メモリ設定など）を誰かが提案できますか？

参考までに-サーバーには大量の空きメモリと空きCPUサイクルがあるため、リソースの問題ではありません。 string.JoinまたはStringBuilderを使用するようにすべてのコードを書き直します。予算に含まれていません。

4

3 に答える 3

3

これにより、メモリ内に多数の小さな文字列オブジェクトが作成され、後でガベージ コレクターによって収集する必要があります。に置き換えます

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

  // Call sMain.ToString() when you need the whole string
于 2012-11-27T00:18:07.383 に答える
2

RedGates Profiling Toolsを最初に推奨したのは私だとは信じられません。

これにより、サーバーと開発用 PC で何が非常に多くの時間を費やしているかが正確にわかります。

文字列はマネージド ヒープに格納される参照型であるため、ガベージ コレクションの対象となります。GC は、GC がメモリを解放できないことを初めて検出したときに、文字列を世代 (0、1、2) に昇格させます。CLR プロファイラーを見ると、大量の文字列がジェネレーション 2 に割り当てられていることがわかるでしょう。

すべてのコードを string.Join または StringBuilder を使用するように書き直すことは予算内ではありません。

予算内かどうかは関係ありません。アプリケーションが応答するのに 15 秒かかる場合、誰もそれを使用したくなくなり、お金を稼ぐことはできません。何かを変更する必要があります。

プロファイラーのトレースがなければ、暗闇でショットを撮るようなものです...私の最良の推測は、開発用PCにSSDがあることです。

文字列は不変であり、メモリの大部分は、GC が収集できなかった連結された文字列を参照している可能性があります。これがメモリの問題だとはまだ思いません。I/O に関係していると思いますが、プロファイラーのトレースで確認できます。

于 2012-11-27T01:36:54.563 に答える
0

開発ボックスのウェブサイト設定を本番ボックスに差分します。ワーカー スレッド数から最大メモリ サイズまで、さまざまな原因が考えられます。これらのしきい値を超えると、IIS はワーカーをリサイクルします。

また、開発ボックスで IIS または Cassini を使用していますか?

アプリがデバッグ モードで実行されていないことを確認します。

于 2012-11-27T00:28:50.790 に答える