これまで、FastCGI が Windows でサポートされていなかったために、 PHP の運用プラットフォームとしてはどうしても Linux を採用 せざるおえない面もありました。しかし、FastCGI が公式に サポートされたことにより、PHP のプラットフォームとして Windows を提案することも行いやすくなります。
PHP は簡単でパワフルであるが故に初級エンジニアから上級 のエンジニアまで幅広い層に支持されてきました。多くの PHP サイトが運用される一方でコストの都合から、ほとんど アップデートなどがなされないサーバーもあります。 平均的な PHP サイトの管理者にとって Linux 環境の運用は (エンジニアのスキルによっては) 大変骨のおれる作業ですから、 管理の手間を省きたい案件については、今後 Linux に代り (Microsoft Update 一本で済む) Windows Server が プラットフォームとして採用されていくことになるでしょう。
オープンソースウェアとの親和性を高める方向 (スコア: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 サービス起動時に起動しておき、HTTP
リクエスト毎に fork()/exec() せず、事前に起動しておいた
プロセスにリクエストを振り分け処理させることにより、トランザクション
性能やレイテンシ性能を高める技術およびプラットフォームが
FastCGI です。
PHP のような動的なコンテンツ生成を行なう環境では FastCGI
のような常駐サーバー方式による性能改善を行なわなくては現実
的な範囲で性能を得ることは困難だといわれています。
これまで、FastCGI が Windows でサポートされていなかったために、
PHP の運用プラットフォームとしてはどうしても Linux を採用
せざるおえない面もありました。しかし、FastCGI が公式に
サポートされたことにより、PHP のプラットフォームとして
Windows を提案することも行いやすくなります。
PHP は簡単でパワフルであるが故に初級エンジニアから上級
のエンジニアまで幅広い層に支持されてきました。多くの
PHP サイトが運用される一方でコストの都合から、ほとんど
アップデートなどがなされないサーバーもあります。
平均的な PHP サイトの管理者にとって Linux 環境の運用は
(エンジニアのスキルによっては) 大変骨のおれる作業ですから、
管理の手間を省きたい案件については、今後 Linux に代り
(Microsoft Update 一本で済む) Windows Server が
プラットフォームとして採用されていくことになるでしょう。
本事例は FastCGI が公式にサポートされることによりプラットフォーム
として採用される可能性が高くなったという一例にすぎません。
しかし、このように、戦略上オープンソースウェアの利用層を
Windows に取り込むためには、オープンソース活動の支援を通して
オープンソース利用者がどのような機能を必要としているのか
リサーチし、Windows とオープンソースの親和性を高くして
いくことが重要であると考えられているものと推測されます。
Re:オープンソースウェアとの親和性を高める方向 (スコア:2, 興味深い)
えーと、Fast CGI サポートはWindows Server 2003 (IIS6) にも行われています [microsoft.com]。
念のため。
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設定からウェブサーバとしての
設定は切り離せた方がシンプルなので、決定的という程ではないものの
それなりに便利です。