問題タブ [worker-process]

MS コマース サーバーを使用して c# で記述され、32 ビット環境で実行されているかなり大量の ASP.Net サイトがあります。最大 980 メガバイトのワーカー プロセスをよく見かけます。このプロセスのプロファイルを作成し、このサイトのメモリ フット プリントを削減するためにコードを改善できる箇所を特定したいと思います。私の質問は、ASP.Net Web アプリケーションでこの種のことを行うのに、どのツールがうまく機能したか?

私は非常に具体的なフィードバックを提供してくれるツールを探しています。これは、コードで何を変更する必要があるかを明確に理解するのに本当に役立ちます。より具体的なデータセットを比較するために、このツールが本番環境のワーカープロセスをプロファイリングできれば最高です.

[編集]

これまでのところ、Ants と JetBrains の間のトスだというのがコンセンサスのようです。両方使ったことある人いますか？もしそうなら、どちらが優れていましたか、またはそれぞれの長所と短所は何ですか?

1 つのワーカーで 1.2 GB を超える RAM を使用し、より多くのワーカーを使用したい場合、IIS6 の速度低下の問題が発生しています。ただし、ASP セッションはワーカーによって作成されているように見え、ブラウザーが別のワーカーを介してページにアクセスすると、ASP セッションが失われます。

この問題を解決するためのヒントはありますか?

IIS とは別にセッションを管理する別の方法を使用することを検討しています (データベースではなく、おそらく memcache?)。何かお勧めはありますか？

注: アプリケーションはレガシー コードでいっぱいであり、コードの大幅な変更を避ける必要があります。

IIS 6でWebアプリのアプリケーションプールを設定すると、ワーカープロセスはデフォルトで1740分（29時間）でリサイクルされます。

このリサイクルは、Webサイトにアクティビティがある場合でも、または29時間非アクティブな場合にのみ発生しますか？

Kentico CMSを使用しており、Webガーデンの展開についてメールを交換しました。

8つのCPUコアを搭載したサーバーで単一のサイトを実行しています。Kenticoのアドバイスに従って、アプリケーションプールのWebガーデン設定をデフォルトから変更していません。つまり、ワーカープロセスの最大数を1に設定しています。

私たちの経験では、サイトはcpuコアの1つのみを使用しています-他はアイドリングしています。これについてメールを送ったところ、アプリケーションプールにワーカープロセスが1つしかない場合でも、OS / IISがこれを処理し、必要に応じて他のコアを使用するという回答がありました。

今、私はケンティコの人たちをとても尊敬していますが、これは私には正しくないようですか？

確かに、すべてのコアを使用する場合は、8つのワーカープロセスを許可する（そしてSQLサーバーにセッション状態ストレージを実装する）必要がありますか？

どうもありがとう

トニー

スレッドセーフでないコードを .net フレームワークでラップする最良の方法は何ですか?

静的変数を使用しているため、スレッドセーフではないサードパーティのライブラリがあります。それを書き直すことはオプションではありません。このライブラリは、多数の同時呼び出しを受信する asp.net Web サービスによって使用されます。

私は現在、ロックを使用してスレッドの安全性を確保するプロキシ クラスにラップしています。

複数の呼び出し元がロックを待機する必要があるため、パフォーマンスは低下しますが、結果は正しいです。

このライブラリの複数のインスタンスをそれぞれ独自の AppDomain で実行することにより、パフォーマンスを向上させたいと考えています。これは合理的なアプローチですか？推奨する良いサンプル コードはありますか?

単純なWindowsサービスを構築している最中で、小さな問題が発生しています。

サービスは正常に実行され、OnStartメソッドは着信UDP接続をリッスンするワーカープロセスを作成します。

私が抱えている問題は、サービスで[停止]または[再開]をクリックすると、サービスがタスクマネージャーで実行されたままになることです。何が間違っているのかわからない。

IIS 7 および ASP.net 3.5 に適用されるため、ASP.NET セッション状態について理解する必要があります。

アプリケーションがインプロセス セッション状態を使用するように構成されている場合、複数のワーカー プロセスが存在しても問題なく動作しますか? つまり、ワーカー プロセスはセッション状態を共有しますか?

IIS 7 の既定の構成では、インプロセス セッション状態を使用し、最大 10 個のワーカー プロセスを割り当てます。その場合、このデフォルト構成が機能するはずです。問題が発生している ASP.NET MVC Web アプリを作成した会社と取引しています。彼らはサーバー環境を非難しています。主張は、10 個のワーカー プロセスのデフォルト設定を使用しているため、セッション状態が壊れているということです。これが実際に正確な主張であるかどうかを知る必要があります。ASP.NET アプリが既定の構成で動作しないことを知らなかったので、少し混乱しており、これを明確にする必要があります。

ASP.NET Webアプリケーションを許可するワーカープロセスの数を決定するためのベストプラクティスは何ですか？

私が管理している1つのサーバーで、新しいAppPoolを作成すると、デフォルトで10（最大）ワーカープロセスになります。他の人は、通常の設定は1つであると提案しています。

複数のワーカープロセスはどのような問題を解決し、いくつを決定するためのテクニックは何ですか？

私はDjango Webアプリケーションを持っており、バックグラウンドで動作する（または実際には開始される）タスクがいくつかあります。

アプリケーションは次のようにデプロイされます。

• apache2-mpm-worker;
• デーモン モードの mod_wsgi (1 プロセス、15 スレッド)。

バックグラウンド タスクには次の特徴があります。

• 一定の間隔 (約 5 分ごと) で動作する必要があります。
• アプリケーション コンテキストが必要です (つまり、アプリケーション パッケージがメモリ内で利用可能である必要があります)。
• 電子メールの送信やデータベースの状態の更新など、それほど重くないタスクを実行するために、データベース アクセス以外の入力は必要ありません。

現在、この問題に対する最も単純なアプローチは、(mod_wsgi によって生成された) 既存のアプリケーション プロセスにピギーバックすることだと考えていました。タスクをアプリケーションの一部として実装し、それに HTTP インターフェースを提供することで、すべてのアプリケーションをメモリに保持している別のプロセスのオーバーヘッドを防ぐことができます。この HTTP インターフェイスに 5 分ごとにリクエストを送信する単純な cronjob をセットアップできます。アプリケーション プロセスは 15 のスレッドを提供し、タスクは非常に軽量で 5 分ごとにしか実行されないため、Web アプリケーションのユーザー向け操作のパフォーマンスが妨げられることはないと思います。

それでも...私はいくつかのオンライン調査を行いましたが、このアプローチを支持する人は誰もいません. 多くの記事では、本格的なメッセージング コンポーネント ( RabbitMQ を使用する Celery など) に基づく、より複雑なアプローチを提案しています。それはセクシーですが、私にはやり過ぎに思えます。一部の記事では、タスクを実行するスクリプトを実行する cronjob を設定することを提案しています。しかし、それもあまり魅力的ではありません。アプリケーション全体をメモリにロードし、いくつかの小さなタスクを実行し、プロセスを再び破棄する新しいプロセスを作成することになるからです。そして、これは5分ごとに繰り返されます。エレガントなソリューションのようには聞こえません。

そのため、前の段落の前の段落で説明したように、提案したアプローチについてのフィードバックを探しています。私の推論は正しいですか？(潜在的な) 問題を見落としていませんか? アプリケーションのパフォーマンスが妨げられないという私の仮定はどうですか?