アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
計算機科学者とは、壊れていないものを修理する人々のことである
オープンソースウェアとの親和性を高める方向 (スコア:2, 参考になる)
狙っているものと推測します。
一例として、Windows Server 2008 から FastCGI のサポートが
入りました。
http://blogs.msdn.com/dd_jpn/archive/2007/04/18/2168928.aspx
FastCGI とは、IIS や Apache などで PHP スクリプトなどを
高速に実行する技術です。ご存知の通り、CGI 実行の際には
CGI 実行のためプロセスが新たに生成されますが、プロセス生成
は OS にとって重い処理であり、動的コンテンツ生成の際には
ボトルネックとなりやすかったのです。これを常駐サーバーとなる
プロセスを HTTP サービス起動時に起動してお
Re:オープンソースウェアとの親和性を高める方向 (スコア:1, すばらしい洞察)
プロセス生成のコストを抑えたいならば、ウェブサーバに拡張モジュールとして組込む方が良いし、処理性能が必要なサーバでは当然行なわれている。
FastCGIは、CGIとして作成されたプログラムを、最小限の変更で半常駐化するための機構であり、中途半端な解決策でしかない。
# もちろん使えないよりは使えるほうが良いけど、今更、新規の開発でFastCGIを選択する積極的な理由は無いでしょ。
Re:オープンソースウェアとの親和性を高める方向 (スコア:1, 興味深い)
確かに間違って無いんだけど、あまり理解してないでしょ?
そもそも、WindowsServer上でPHPは、Apacheのモジュールとして動かそうが、
IISでASAPIとして動かそうが、Linux+Apache+mod_phpの数倍~十数倍レベルで重いです。とても実用的じゃない。
そこにやっとFastCGI for IISという環境が出来て、そこそこの速度でWindowsServer上でPHPが動かせるようになったのよ。
でもmod_rewriteが無いのでPHPのフレームワークはほぼ全滅。
だからやっぱりFastCGIを選択する積極的な理由は無いんだけど、WindowsServerでPHP、
という縛りがあるならFastCGI for IIS一択なのは確かなんだよ。
Re: (スコア:0)
その分有利。共有環境とかだとこれ重要。
もちろん従来(といってもFastCGIはすごく前からあるけど)から
ウェブサーバ2段重ね構成などで同じメリットは享受できましたが、
言語ランタイムをFastCGI対応にする方が各ウェブサーバ固有の
モジュールにするより楽なのと、FastCGI設定からウェブサーバとしての
設定は切り離せた方がシンプルなので、決定的という程ではないものの
それなりに便利です。