09/04/01 11:08:56
作る際の効率が問題なら、そもそもwebアプリでCは選択しちゃダメ。
5年って、アナタたぶん作ったことないから死ぬほど安全に見積もってるよね?
アプリケーションサーバって、そこまで作るの大変じゃないよ。やることは基本的に待つだけだし。
実際は余暇を二週間位でも最初のプロトタイプ位はできるんじゃ...
まぁ、既存の適当にかかれたCGIをスレッド対応にするのは骨がおれると思うけど。
libaprのメモリプールの返却云々については、apr_pool_create の第二引数参照。
作業とか、ループとかにサブプールを作って、必要なメモリはそこから確保して、
終わったらサブプールだけ開放するって感じで。
でも、確かにCGIじゃないのでもうやめます。
fastcgiもCGIじゃないのではって気するけど...
504:nobodyさん
09/04/02 22:00:32
C言語が向いてるのは、開発費が多少増えたとしても、
サーバ台数が抑えられるから、トータルコストが安くて済むような案件だね。
検索サーバとか、2chとか、アクセス数が多いサイトとかね。
505:普及された人
09/04/04 11:18:37 JlRZ3FIj
>>503
はい、もちろん作ったことはありません。
それに、今までのところでは作る必要性も感じたことはありません。
私がＣ言語で既存のＡＰＩを利用せずにアプリケーションサーバを作ることを考えると、、、
FastCGIのようにアプリケーションサーバ（これはハードのことです）側にある複数のTCPクライアントCGIと通信をこなしながら処理を進めることや、
アプリケーション側に、どのようにどのくらいのメモリを与えるのかなどを考えると、
できるだけ汎用的なものにしようとすれば、TCP先で利用できるlibaprのようなＡＰＩを自分で作らないといけないし、、、
というような感じで、503さんとは少し論点がずれていたようです。
すみません。
だた、やっぱり基本的な考え方としてはFastCGIは
（Client → WebServer → FastCGI → CGI → FastCGI → WebServer → Client）
という形態ですので、アプリケーションサーバもFastCGIとほぼ同じで、
（Client → WebServer → AppServer → App → AppServer → WebServer → Client）
という形態になり、module型
（Client → WebServer(module型App) → Client）
の方が構成がかなり単純ですので、Ｃ言語で作ったCGIやAppの反応はかなり高速だと思います。
それに、やっぱりmodule型のＣ言語Appを一つ作る方が、
アプリケーションサーバとクライアントアプリケーションの両方を作るよりも遥かに楽だと思います。
それ以上に、FastCGIであれば、
FastCGI用Ｃ言語ＣＧＩを一つ作れば済みますので、労力は激減します。
ただ、やっぱりアプリケーションサーバはもとよりmocule型AppもCGIではありませんね。
あと、FastCGIはCGIプログラムをメモリ上に常駐させるのかさせないのかという違いで、基本的な仕組みはＣＧＩと同じと考えて良いと思います。