5

「コスト」という話題が出てきたら、同僚と私がWFCサービスについて話し合っています。

質問はこれです：

IISがホストするWCFサービスとWindowsサービスがホストするWCFサービスがまったく同じことを行うとすると、両方が同じ負荷を受け入れる場合、メモリとCPUサイクルに関してどちらのサービスがより「高価」になりますか？

私たちは、初期の起動時のコーディング、インストール、または構成（IISがよりシンプルなエクスペリエンスを提供するように調整されているようです）については気にせず、サービスを実行するための最低限のコストだけを気にします。

4

3 に答える 3

3

具体的な数値を提供することはできませんが、これが大きな懸念事項である場合は、確実にパフォーマンス テストを行う必要があります。典型的な HTTP ベースの WCF サービスの場合、すべての要求は最初に Windows 内の http.sys によって処理され、次に適切なプロセスにディスパッチされます。サービスが IIS またはスタンドアロンでホストされているかどうかは、呼び出しごと、セッションごと、またはシングルトンの構成、および要求サイズの制限と要求の調整に関して、使用する WCF 固有の構成設定ほど重要ではありません。

私はユーザビリティと、厳密にパフォーマンスの数値よりも理にかなっていることに焦点を当てます。それらはほぼ同じでなければならないからです。

結論: より便利なものを使用し、必要に応じてパフォーマンス テストを行います。

于 2010-02-16T18:13:34.957 に答える
2

WCF の IIS または Windows サービス ベースのホスティングの間で非常に重要なパフォーマンスの考慮事項の 1 つは、バインドの種類です。IIS は、HTTP 経由で機能する WCF バインディングのみをサポートしますwsHttpBinding。basicHttpBindingなど

一般に、 netTcpBinding (サービスとクライアントの両方が WCF ベースであることが必要) やnetNamedPipeBinding (最速ですが、サービス/クライアントは同じマシン上にある必要があります)などの非 HTTP バインディングは、パフォーマンスが優れていることが知られています。もちろん、これらには独自の制限があり、特に柔軟性があります。

概要は次のとおりです。 http://weblogs.asp.net/spano/archive/2007/10/02/choosing-the-right-wcf-binding.aspx

ここで非常によく似た議論がありました: WCF Binding Performance

于 2010-02-16T20:09:58.670 に答える
2

これがあなたの質問に完全に答えるわけではないことは承知していますが、私の経験を共有したいと思います。

IIS でホストされている WCF サービスをスケジュール時に呼び出す Windows コンソール アプリケーションがあります。このアーキテクチャでは、IIS は実際には完全に不要であり、ソリューション全体に対する単なる追加コンポーネントです。これは、技術的な理由ではなく、製品を強化するためのマーケティング上の理由でソリューションに実際に含まれていました.

これらは私が直面している主な問題であり、技術的な理由から可能であれば IIS の使用を避けていた理由であり、これは私の経験にも当てはまります。注: IIS で WCF サービスをホストすることが悪い考えだと言っているわけではありません。現在取り組んでいる製品からの考えを述べているだけです。

  1. IIS をループに含めるということは、ソリューション全体に別のシステムを含めることを意味します。これにより、展開が複雑になります。一部のクライアントは IIS6 を使用しており、他のクライアントは 7 を実行しています。間違いなく、それらはまだ異なります。つまり、製品を異なるクライアントに展開している場合、環境の違いの可能性がさらに増えることになります。これらの違いを過小評価しないでください。SharePoint サイト コレクション内で WCF サービスを実行しようとしているクライアントもいます (当然です!) ポイントは、あなたが間違っている可能性があると思うよりもはるかに多いということです。
  2. IIS には AppPool に関する考慮事項もあり、製品の複雑さに応じて構成する必要がある場合があります。その AppPool には、実行するための ID が必要であり、ソリューション全体がさらに複雑になります。
  3. 単一のスレッド化されたサービスに「興味深い」スレッド中止メッセージが表示されることがあるという問題がいくつかありました。私はまだ正確な原因を突き止めようとしていますが、私の心の奥底では、これが IIS に何らかの形で関連していないことを心から願っています。要点は、ソリューション全体から IIS を排除した場合、この考慮事項はなくなるということです。
  4. IIS は、WCF サービスに対して自己ホスト型よりも堅牢なホスティング環境であるという議論を聞いたことがあります。これが重みを持っているかどうかは完全にはわかりません。自分が何をしているのかを知っていれば、自己ホスト型サービスが信頼できない理由はないはずです。しかし、WP のリサイクルなど、IIS で得られる自動機能のいくつかを実装するには、事前にもっと作業が必要だと思います。
  5. ループ内の IIS に全体的に満足しているわけではありませんが、展開のために製品を引き渡すときは苦痛であり、十分な技術的バックグラウンドを持たないコンサルタントが IIS アプリケーションをセットアップする必要があります。通常、何か問題が発生する可能性があり、問題が発生する可能性があり、より技術的な経験を持つ誰かが介入して解決する必要があります。セルフ ホスティングを使用している場合は、展開用にアプリをより簡単にパッケージ化できます。
  6. 繰り返しになりますが、IIS を選択すると、ソリューションに 1 つではなく 2 つのアプリケーションが含まれることになります。ただし、組織のビジネス側はアプリを 1 つのビジネス ユニットとしてしか見ておらず、基本的にソリューションの複雑さを完全には理解していません。あなたが実装しています。例: 2 つの構成ファイルがあるのはなぜですか? メールを 2 回構成する必要があるのはなぜですか? DLL を 2 つの場所に配置する必要があるのはなぜですか。これらの質問はよく聞かれます。
  7. 最後に、クライアントに展開するためにリモートまたは VPN 経由で作業している場合、状況はさらに悪化します。コンサルタントが、あなたがアクセスできない機密領域にアクセスできる場合があります。開発者として、ソリューション全体から余分な荷物をできる限り排除しようとします。また、システム管理者が便利な IIS リセットを発行する場合があることにも言及しましょう。アプリが他のアプリと一緒にホストされている場合、サービスがリセットされます。

私の経験ではシステムが少ない = 失敗する可能性が少ない。ただし、信頼できるセルフ ホステッド サービスを実装するスキルがあるかどうかを判断する必要があります。これはすべて、開発、展開、および保守のコストに直接関係しています。

于 2010-02-17T11:37:45.033 に答える