Rebol (現時点では Apache 2 の CGI) でかなりまともなサイズの Web アプリケーションを作成する予定ですが、最初のパフォーマンス テストでは非常に落胆しました。アプリケーションで apache ベンチマークを実行すると、1 秒あたり 4 ～ 5 リクエストしか取得できません。他の人が同様の問題を抱えているかどうか、FastCGI が本当に彼らを助けたかどうかを知りたいです。
ところで、Rebol は Command と SDK のバージョンでのみ FastCGI をサポートしていますが、R3 がオープンソース化されてから、これはすぐに変更されるのでしょうか?
RebolのFastCGI機能を使用してからしばらく経ちましたので、最初の質問にうまく答えることはできませんが、2番目の質問については、気に入らないかもしれませんが、お手伝いできます。
fastcgi://R3のスキームはまだ誰も再現していません。R3のポートモデルはR2とは完全に異なるため、「再作成」と言います。そのため、ポートスキームは2つのプラットフォーム間でまったく移植できません。これは、R2 /コマンドポートスキームが組み込みのネイティブコードであることに加えて、R3のシステムモデルも異なるため、オープンソースであってもR3に移植できません。そして、その移植性に関係なく、R2には、Rebol Technologiesがオープンソースを開く権利を持たない多くの商用ライセンスコードが含まれています。R2で開くことができるほとんどすべてのものが、すでにR3に組み込まれています。したがって、まだ存在しない場合は、互換性がまったくないか、開くことができないと考えるのが安全です。
fastcgi://R3モデルに続くまったく新しいスキームを使用すると、R3で最初からやり直す方が速くて簡単です。R2ソースが最も役立つのは、たとえそれがあったとしても、FastCGIプロトコルを文書化することであり、AFAIKプロトコルは他の場所でより適切に文書化されています。その場合は、この種のことに最適化されたホストポートを作成することをお勧めします。これは、R3で行うのが少し簡単です。
プラス面としては、FastCGIプロトコルを実行するのはそれほど難しくなく、新しいR3ポートモデルはこの種のことにははるかに優れているので、最初から始めるのはそれほど難しくないかもしれません。運が良ければ、これはすべて、通常のR3インタープリターで実行されるユーザーコードで実行できます。ホストコードを調整する必要はありません。したがって、ニュースはそれほど悪いものである必要はありません。
今あなたの最初の質問に答える試み：それは異なります。
それは本当にあなたが何をしようとしているのか、そしてあなたが物事をどのように設定しているかに依存します。CGIには毎回プロセスを開始するオーバーヘッドがあるため、プロセスの起動オーバーヘッドがリクエストの残りのオーバーヘッド（ファイルシステムやデータベースアクセスなど）よりも大幅に少ない場合にのみ高速になります。Rebol、特にR2は、起動時にロードするための組み込みの解釈済みコードを備えたインタープリターであるため、プロセスの起動にかなりのオーバーヘッドがあります。SDKを使用して必要なコードのみでアプリを作成することで、起動のオーバーヘッドを最小限に抑えることができますが、それでも特定のケースでは十分に役立たない場合があります（何をしようとしているのかわからない）。
FastCGIは、リクエストごとに新しいプロセスを開始する代わりに、アウトプロセスのアプリサーバーを実行することにより、そのプロセスの開始オーバーヘッドを取り除く方法です。プロセスの起動オーバーヘッドが大きいRebolのようなものの場合、節約は同じくらい重要です。
考慮する必要があることの1つは、R2にはほとんどの部分でプロセスごとのシングルスレッドモデルがあるため、複数の同時リクエストを処理する場合は、同じプロセス（ノードなど）の一部でそれらを実行する必要があります。 js）または、FastCGIに複数のサーバープロセスを割り当てて、複数のリクエストを個別に処理するか、またはその両方を実行させます。これが恐ろしい可能性がある場合は、必ずRebolの専門家にアドバイスを求めるか、FastCGIを設定して、同時に実行するアプリサーバーをさらに起動してください。
したがって、FastCGIセットアップで1秒あたりに実行できる要求の数は、FastCGIの構成方法、FastCGIハンドラーコードの記述方法、および要求が実行している作業の量と種類によって異なります。
ただし、CGIモードでは1秒あたり4〜5件のリクエストを受け取っていることを示しています。それは異常に遅いです。Rebolの起動時のオーバーヘッドは、最悪の場合、それほど遅くはありません。これは、リクエストが多くのことを実行しているか、一度に2つ以上のCGIプロセスを実行するのに十分なRAMがないか、CGIが正しく構成されていないことを意味します。その場合、FastCGIが、より優れたハードウェアを使用したり、Apacheをより適切に構成したりするのと同じくらい役立つかどうかはわかりません。それでも、十分なFastCGIワーカープロセスがあり、同時に複数のリクエストを処理するハンドラーを作成することを確認してください。そうすれば、可能な限り多くのオーバーヘッドを節約できます。
幸運を！
実行しようとしているスクリプトがわからない場合、パフォーマンスの問題に答えるのは困難です。:-) 以下の質問のいくつかはばかげているように思えるかもしれませんが、Rebol CGI を試している状況についてはあまり知りません。
4 ～ 5 リクエスト/秒は、Apache で実行されている CGI アプリでは正常ではありません。たとえ 10 年も前のどんな種類の H/W であっても、それ以上のものを手に入れることができるはずです。
どのようなテストを行っていますか？私にとって、rebol は非常に速く起動するので、開いてコンソールを表示し、更新の合間に (60Hz で) 終了することができるので、表示されることさえありません。
コード (または使用するライブラリ) の一部に遅延またはわずかな待機がある可能性があります (DB サーバーへのネットワーク遅延の可能性があります)。
また、サーバーの発信ネットワーク速度をテストしましたか?
また、Rebol で構築された Web サーバーである cheyenne を試すこともできます。これは、1 秒あたり数百の要求を処理できますが、スクリプト自体にそれほど時間がかからないことは明らかです。
実際、cheyenne と apache はサーバーのネットワーク速度を比較的簡単に飽和させることができるはずです...長いスクリプトがあり、より多くのスループットが必要な場合は、ワーカーを追加して並列タスクを増やします (メモリ使用量が許容範囲内である限り)制限)
If you can get ~30 rps on the same box using Ruby and same performance between Ruby and Rebol on a Windows box, most probably, something is wrong with your Rebol CGI and/or configuration.
Try running your Rebol CGI script from command-line in a loop to see if the cause of the slowness is the script or your Apache config.
いくつかの他の方法:
シャイアンのような実際の rebol-webserver への apache play プロキシを許可します。起動時などに実行し続けるのはより複雑です。
パイプを介して別の言語の背後で rebol を実行します。fastcgi のある言語を使用してください。
rebol を tcp-daemon として実行し、fastcgi-language に接続させます。