誰かがCGIに関するgolangのドキュメントからのこの抜粋を説明してもらえますか:
" CGI を使用することは、各要求を処理するために新しいプロセスを開始することを意味することに注意してください。これは、通常、実行時間の長いサーバーを使用するよりも効率的ではありません。このパッケージは、主に既存のシステムとの互換性を目的としています。"
CGI を使用して、データベースの put と get を作成します。
これは非効率ですか？「長時間実行サーバー」を使用する必要がありますか?
もしそうなら、それはどういう意味ですか、どうすれば実装できますか?
はい、非効率的です。まったく新しいプロセスを開始するコストは、通常、既存のプロセスに接続したり、現在のプロセス内のスレッドで何かを実行したりするだけではありません。
それが必要かどうかという点では、それは異なります。あなたがグーグルに匹敵する検索エンジンを作成しているなら、私はCGIが行く方法ではないことを提案します。
1時間に1回アクセスする個人のWebサイトであれば、おそらくそれを回避できると思います。
長時間実行されるサーバーに関しては、通常、常に実行されているWebサーバーのプラグインのようなものを記述でき、Webサーバーは必要に応じて（場合によっては「it」の複数のスレッドで）要求をサーバーに渡します。 。
そうすれば、いつでも準備ができており、Webサーバーがリクエストを処理するために別のプロセスを開始するまで待つ必要はありません。
実際、Apache自体は実行時にApacheに統合されるモジュール（プラグインなど）を介してCGIを実行します。外部プロセスの実際の呼び出しは、そのモジュールから処理されます。ソースコードは、役立つと思われるmod_cgi.c場合は、Web検索を行うとに見つかります。
もう1つの例は、このリンクmod_perlから入手できるPerlインタープリターモジュールです。
調べるオプションの 1 つは fastcgi です。これは、各リクエストを継続的に再起動しない長時間実行されるサーバー プログラムです。以前は、C、C++、FPC などの言語はガベージ コレクションされていないため、時間の経過とともにメモリ リークが発生するため、高速な cgi には欠点がありました。通常の古い CGI はガベージ コレクターそのものでしたが、Web サイトに何百万回もヒットした後の 1 つの fastcgi プログラムでの小さなメモリ リークにより、サーバーがダウンする可能性がありました。プログラムは再起動し、誰かがページを要求して cgi が終了するたびにクリーンアップされました。Go lang の場合、メモリ リークは問題になりませんが、高速な cgi には次のような隠れた問題がある可能性があります。golang のガベージ コレクタ自体にメモリ リークがある場合...ヒープの断片化 .... 時間の経過とともに..)
一般に、fastcgi と「長時間実行」は時期尚早の最適化です。個人のホームページの Web サイトに 1 日に 5 人の訪問者がいて、実際には 1 日に 500 万人の訪問者が必要なときに、「ちょっと、fastcgi を使用する必要があるかもしれません」と叫んでいる人を見てきました。彼らのサイトが 3 人に知られる前に、高速な cgi を作成しました。
自問する必要があります: 使用しているサーバーには大量のトラフィックがありますか? 大量のトラフィックとは、1 日 100 人の訪問者を意味するものではありません... 1 日 1000 人のユニークな訪問者でさえ多くありません。
apache サーバー用の Go lang cgi プログラムを作成したいのか、go サーバー用の python プログラムを作成したいのか、または python と perl 用の cgi 機能を備えた go サーバーを作成したいのかどうかは不明です。実際に行っていることを明確にします。
誰かが別の回答で投稿した検索エンジンとしての Google に匹敵することについては、Google の歴史を見ると、彼らは実際には PHP、perl、または他のヒップを使用するのではなく、何らかの cgi システムを介して C++/C でプログラムをコーディングしていました。そして子供たちが使うクールなもの。何十年も前の backrub プロジェクトとそのテンプレート システムを調べてください。それは Ctemplate (html テンプレートで呼び出される C でコンパイルされたプログラム.....) と呼ばれていました。
https://www.google.com/search?safe=off&q=google+backrub+template+ctemplate
Fastcgi は、fastcgi が登場する前に Google が考え出したものだったのかもしれません。あるいは、fastcgi に似た独自の独自のソリューションを持っていたのかもしれません。昔は（そしておそらく今日でもいくつかのものについては）、速度のために修正されたCGIテクノロジーであったとしても、彼らは何らかのCGIテクノロジーを使用していたに違いありません。