3

個別のプロセスとして実行され、適切な IPC によってリンクされる 3 ~ 4 つのサービスで構成されるアプリケーションを設計しています。システムには Web インターフェイスがあり、そこにある Web サーバーを使用したいと考えています。

Web インターフェースは、同じ Web サーバー上でまったく異なることを行う他の URL を持つことを許可する URL でアクセスする必要があります。その URL の下のパスを使用して、Web インターフェースが何をすべきかを指定する予定です。これには、ネット上で他のアプリケーションが使用したり、人間がブラウザーで対話したりするための機能があります。

袖口から、私は次のように働きます:

  • ウェブサーバーが受信するすべてのリクエストに対して CGI プロセスを開始するようにします (Apache の SetHandler など)。
  • CGI を IPC に接続させます
  • バックエンド サービスから必要なものを取得できるようにする
  • サービスの回答に基づいて、CGI が HTML / XML および HTTP ステータスを返すようにします。

今、私が本当に望んでいるのは、最初の 2 つのステップを回避することです。それができない場合は、2 番目のステップを回避することです。これは、不必要なオーバーヘッドでパフォーマンスを浪費しているのではないかと心配しているからです (他のアプリケーションからの要求は頻繁に発生する可能性があります)。 )。

たとえば、PHP は MySQL データベースへの永続的な接続を開くことができます。この接続は、スクリプトの実行後も存続し、次回再作成する必要はありませんが、実際にどのように行うのかはわかりません。また、私が理解しているように、サーバーの起動時にApacheモジュールが一度ロードされるため、最初のステップが削除される可能性がありますが、Apacheに結び付けられます.

では、特定の URL のハンドラーを別の Web サーバーにフックする良い方法は何でしょうか? HTTP を処理したくありません。それ以外の場合は、2 番目のサーバーへのプロキシ設定を使用するだけかもしれませんが、車輪の再発明のようです。CGI は問題ないと思われ、同様の構造の大量のリクエストを処理する例があれば教えてください。

4

2 に答える 2

5

OK、以前はこれを見落としていました。ここで私の質問を説明すると、私はそれに気づきました:

FastCGIは、リクエストごとに新しいプロセスを作成する代わりに、その存続期間にわたって多くのリクエストを処理する単一の永続的なプロセスを使用できます。-ウィキペディア:FastCGI

于 2008-09-26T14:16:50.357 に答える
3

中程度の負荷がかかったとしても、CGI は非常にスケーラブルではありません。FastCGI はオプションですが、XXXX が言語の名前である mod_XXXX パッケージもおそらく見つかるでしょう。たとえば、ruby、perl、python の mod があり、おそらく他にもかなりの数の mod があります。

于 2008-09-26T15:40:32.933 に答える