48

ServiceStack Webサイトにリストされているのは、ServiceStackが次のいずれかを使用してMonoで実行できることを示しています。

  • XSP
  • mod_mono
  • FastCgi
  • コンソール

これらの異なる構成は何ですか？MonoのWebサービスに適していますか？

4

5 に答える 5

84

Linux用のアップデート

v4.5.2リリースからServiceStackは.NETCoreをサポートするようになりました。これは、共有クロスプラットフォームコードベースから派生し、Microsoftの十分なリソースを備えた、アクティブで応答性の高いチームによってサポートされる、Monoよりも大幅なパフォーマンスと安定性の向上を提供します。現在MonoでServiceStackを実行している場合は、.NET Coreにアップグレードして、その優れたパフォーマンス、安定性、および上から下までサポートされるテクノロジースタックを利用することを強くお勧めします。

モノのアップデート

LinuxおよびMonoでASP.NETサイトをホストするための推奨セットアップは、nginx/HyperFastCgiを使用することです。mono-server-configでdeploy/install / conf / initスクリプトを使用して、UbuntuVMを最初から作成するためのステップバイステップガイドを公開しました。

いくつかの安定性とパフォーマンスの問題に気付いた後、MonoFastCGIは推奨されなくなりました。このブログ投稿は、 MonoのさまざまなASP.NETホスティングオプションのパフォーマンス、メモリ使用量、および安定性の優れた分析を提供します。

発達

XSPは、VS.NET WebDevサーバー（C＃で記述された単純なスタンドアロンASP.NET Webサーバー）に似ています。これは、開発または小さな作業負荷に適しています。ServiceStack ASP.NETホストのルートディレクトリから実行するだけで、で利用できるようになりますhttp://localhost:8080。

製造

外部インターネットサービスの場合、通常、フル機能のWebサーバーの一部としてServiceStackWebサービスをホストする必要があります。Linuxで最も人気のある2つのフル機能のWebサーバーは次のとおりです。

Nginx

Mono FastCGIを使用して、 NginxでServiceStackASP.NETホストをホストします。

Apache

mod_monoを使用して、ApacheHTTPサーバーでServiceStackASP.NETホストをホストします。

セルフホスティング

ServiceStackは、スタンドアロンのコンソールアプリケーション（つまり、Webサーバーなし）でServiceStackWebサービスを単独で実行できるセルフホスティングもサポートしています。これは、フル機能のWebサーバーのサービスが必要ない場合に適しています（たとえば、Webサービスをイントラネットで内部的にホストする必要があるだけです）。

デフォルトでは、同じServiceStackコンソールアプリバイナリがWindows/.NETとMono/Linuxの両方でそのまま実行されます。ただし、必要に応じて、ここで概説するように、アプリケーションをLinuxデーモンとして実行するように簡単にデーモン化できます。wikiページには、NginxまたはApacheリバースプロキシの背後で実行するようにセルフホストWebサービスを構成するための手順も含まれています。

12ファクターアプリのセルフホスティングで詳しく説明されているように、Herokuの同時実行モデルに最適であるため、近い将来、サポートを強化する予定です。

ServiceStack.net Nginx /MonoFastCGI構成

servicestack.net Webサイト自体（すべてのライブデモを含む）は、Nginx + MonoFastCGIを使用するUbuntuhetznervServerで実行されます。

このコマンドは、FastCGIバックグラウンドプロセスを開始するために使用されます。

fastcgi-mono-server4 --appconfigdir /etc/rc.d/init.d/mono-fastcgi 
  /socket=tcp:127.0.0.1:9000 /logfile=/var/log/mono/fastcgi.log &

XSPのWebAppファイル形式/etc/rc.d/init.d/mono-fastcgiを使用して指定されたフォルダー内の*.webappファイルで定義されたすべてのアプリケーションをホストします。例：

ServiceStack.webapp：

<apps>
<web-application>
        <name>ServiceStack.Northwind</name>
        <vhost>*</vhost>
        <vport>80</vport>
        <vpath>/ServiceStack.Northwind</vpath>
        <path>/home/mythz/src/ServiceStack.Northwind</path>
</web-application>
</apps>

これにより、FastCGI Monoプロセスがバックグラウンドで実行され、次のルールをnginx.confに追加することで、Nginxに接続させることができます。

location ~ /(ServiceStack|RedisAdminUI|RedisStackOverflow|RestFiles)\.* {  
   root /usr/share/nginx/mono/servicestack.net/;  
   index index.html index.htm index.aspx default.htm Default.htm;  
   fastcgi_index /default.htm;
   fastcgi_pass 127.0.0.1:9000;  
   fastcgi_param SCRIPT_FILENAME /usr/share/servicestack.net$fastcgi_script_name;
   include /etc/nginx/fastcgi_params;  
}

/ServiceStackこれは、またはなどで始まるルートを/RedisAdminUIFastCGIモノサーバープロセスに転送して処理します。この方法でホストされているアプリの例：

興味のある方は、servicestack.netの完全なNginx+FastCGI構成ファイルをダウンロードできます。

于 2012-08-30T00:31:59.503 に答える
19

本番環境では、Unix ファイル ソケットで nginx を使用します

nginx、サービススタック、モノでソケット通信を使用する際にバグ/メモリリークが発生することが判明しました。これは 500 の同時リクエストの場合で、CPU とメモリの急増が予想されますが、再びダウンすることはありませんでした。問題がどこにあるかを発見するための追加のテストは行いませんでしたが、xamarin bugzillaでログに記録されたバグがあり、これは私たちが抱えていた問題と似ていると思われます。基本的に、次のことを試してみましたが、それで十分でした。

次のコマンド params で UNIX ソケットの使用に切り替えました

fastcgi-mono-server4 /filename=/tmp/something.socket /socket=unix /applications=/var/www/

この方法の問題点は、fastcgi-mono-server4 を実行するたびにソケット ファイルのアクセス許可が変更されるため、fastcgi-mono-server4 を開始した後に修正する必要があることです。もう 1 つの欠点は、私たちのボックスでは約 120 の同時要求しか処理できないことです。ただし、これは現時点では実際の問題ではなく、いつでもより多くのプロセスを生成できます。

お役に立てれば

于 2012-09-06T10:53:51.680 に答える
6

免責事項：私はHyperFastCgiサーバーの作成者であり、ブログ投稿の作成者はcecoの回答で言及されました

nginx とHyperFastCgiがこの仕事をします。HyperFastCgi は、単一の fastcgi サーバーとしてメモリをリークせず、はるかに高速に実行します。これは、低レベルの単一 API を使用して、クロスドメイン呼び出しの遅い単一 JIT 実装ではなく、アプリケーション ドメイン間でデータを渡すためです。また、ソケット通信にネイティブのlibeventライブラリを使用するオプションもあり、現在の mono System.Net.Sockets 実装よりも約 1.5 ～ 2 高速です。

HyperFastCgi の主な機能:

  • ソケットとクロスドメイン通信を処理する 3 つの異なる方法を使用できます。
    • Managed Listener with Managed Transport(マネージ コードのみを使用し、非同期の System.Net.Sockets を使用します。JIT クロスドメイン呼び出しが遅いため、mono では低速です)
    • Managed Listener with Combined Transport(非同期の System.Net.Sockets をリスナーとして使用し、クロスドメイン呼び出し用の低レベルの mono API を使用します。はるかに高速です)
    • Native Listener(ネイティブlibeventをソケット ライブラリとして使用し、低レベルの mono API を使用してクロスドメイン呼び出しを行います。最高のパフォーマンス)
  • ThreadPool、.NET 4.5 タスク、またはシングルスレッドを使用して、Web 要求を並列化するいくつかの方法を許可します。最後のオプションを組み合わせるとNative Listener、Web サーバーは次のように機能しますNodeJS。すべてのリクエストは、シングル スレッドで非同期的に処理されます。
  • System.Web をまったく使用せずに単純な要求ハンドラーを作成できます。これにより、リクエストの処理パフォーマンスが 2 ～ 2.5 倍向上します。
于 2014-09-28T04:23:49.290 に答える
3

ServiceStack を使用した Mono のパフォーマンスに関する参考になる比較的最近のブログ投稿があります。サービスをホストする方法を決定しようとしている人にとっては役立つと思いました: Mono での Servicestack のパフォーマンス。

それが言うように - FastCGI Mono サーバーには、私が確認できる大量のメモリ リークがあります。ab -n 100000 -c 10 http://myurlMono 3.2.8、Nginx 1.4.6、FastCGI Mono Server 3.0.11、および ServiceStack 3.9.71 を使用して作成されたサービスを使用して、Ubuntu Desktop 14.04 で実行しました。FastCGI Mono Server はリーキー ビットであるため、使用している ServiceStack のバージョンは問題ではないと思います。利用可能なすべてのメモリを消費しました-合計2GBのうち約1GBです。

また、少なくとも他のソリューションと比較すると、Nginx + FastCGI Mono Server のパフォーマンスは悪いです。私のサンプル REST サービスには、1 秒あたり約 275 のリクエストがありました。このブログの著者は、FastCGI Mono Server のコードを見直し、独自の実装を作成することにしました。何らかの理由で、少なくとも私のマシンでは機能しません。

つまり、要点は、FastCGI Mono Server を使用すべきではないということです。ボックスを頻繁に再起動したくない場合を除きます。

この投稿はほとんど否定的なものであるため、サービスのホスティングに関する私の意図は何なのかを述べる必要があります。私はおそらく、Nginx の背後にある AppHost を継承するセルフホスティングに行きAppHostHttpListenerLongRunningBaseます。上記と同じサンプル REST サービスを使用すると、1 秒あたり約 1100 のリクエストが得られます。良いニュースは、プロセスに明らかなリークがなかったことです。約 1000,000 のリクエストでテストしたところ、プロセスは 100MB 未満の RAM を消費していました。

PS私はブログ投稿の著者ではありません:)

于 2014-04-30T09:16:02.310 に答える
2

evhttp-sharp - NancyFx のホストを持つ http サーバー

https://github.com/kekekeks/evhttp-sharp

非常に高速で、nancy-libevent2 よりもほぼ 4 倍高速です。

http://www.techempower.com/benchmarks/#section=data-r8&hw=i7&test=json&s=2&l=2

さまざまな構成のテスト結果があります。

1 秒あたりの JSON 応答数:

  • evhttp-シャープ 91,557
  • nancy-libevent2 17,338
  • サービススタック-nginx-d 953
  • ナンシー 896
  • aspnet-jsonnet-モノ 863
于 2014-11-11T17:17:21.960 に答える