アカウント名:
パスワード:
CGIやアプリを作れと言われれば作れるけど、あのアクセス数を捌けるだけのものは作れないな
今時CGIとか、ここ10年ぐらいの技術に全く付いてこれてないのでは?
CGIってただのインターフェイスだよね?今ではウェブサーバーがCGIでPHPとか他の言語使えたりするけど。
昔の"CGI=Perl"なイメージが強いせいか。
その頃FacebookはPHPを再実装した。(言いたかっただけ)
> 今ではウェブサーバーがCGIでPHPとか他の言語使えたりするけど。PHPは基本的にCGIではないですよ。PHPの言語仕様レベルにウェブサーバへの組み込み機能が含まれており、CGIというインターフェースは使ってません。(PHPをCGIモードで動かすこともできますけど、今時は滅多に使わないですね。昔はPHP3とPHP4の共存のために、片方はCGIモードで動かすなんてこともやったりしましたけど…)
でもまあ、「ウェブサーバとのインターフェース仕様」としては、CGIがほぼ唯一の存在であることを考えると、
・ウェブサーバとは別に、コンテンツ生成プログラムを動かす方式(≒CGI+PHP)・コンテンツ生成プログラム自身がサーバとなる方式(Java Servlet、node.js、Ruby on Rails などなど)
という二方式を対比させる感じですかね。
Twitterのような負荷対策が重要なサービスだと、核となる部分は、独自サーバ方式が有力でしょうね。自分なら node.js を選ぶかなぁ。DBは性能的にKVSにしたいとこですが、フォローした人のツイートの取得とかを考えると、素直にSQLなRDBの方がいいかも。
俺はCGI=MVCだな。色々間違ってるのは分かるが・・・
???ワークフレームのこと?
> CGIってただのインターフェイスだよね?
そもそもCGIが理解できてないですね
CGIは、リクエストが来るたびに、その都度perlなどの別プログラムを子プロセスとして起動する仕組みです。つまりWebサーバと別プログラム間のインタフェースです
そしてCGIは今となってはセキュリティ的にもパフォーマンス的にも問題ありまくりの方法ですましてや「あのアクセス数を捌けるだけのもの」という文脈でCGIなんて単語を出すこと自体があり得ません
> 今ではウェブサーバーがCGIでPHPとか他の言語使えたりするけど。
これは完全に誤りです
今では、CGIを使わず、ウェブサーバーのプロセス内部でPHPなどのインタプリタを動かすのが普通です
> 今ではウェブサーバーがCGIでPHPとか他の言語使えたりするけど。> 昔の"CGI=Perl"なイメージが強いせいか。
昔 = 20年前今 = 15年前
くらいかな?
AmazonのLambdaとかぶっちゃけCGIの考え方と同じだと思うのですが
昔がっつりはまってたCGIのチャットを思い出します。
私ならLAMPで地道に…というところですが技術に付いてこれてないのかなぁ?
最近もそうかは分かりませんがミクシィもMySQLで運用していると記事で読んだこともありますし、大規模運用でも使えるのかも。
自分ならどうする?と言われれば、アウトラインが分かっている堅実そうな方法になってしまいます。
難しいのは負荷分散のほうでネットワークとサーバーの負荷分散の基本構造が出来れば、あとは回線の太さとサーバーの台数を調整するルーチンワークになるイメージです。
ロードバランサーやデータベースのクラスタリングを駆使すれば足りるのか。。。ちょっとそこは分からないなぁ
>CGIやアプリを作れと言われれば作れるけど、あのアクセス数を捌けるだけのものは作れないな
あのアクセス数を捌くのはCGIやアプリの役目ではないです。
mod_cgiの再生産、ありがとうございます。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家
作れるような作れないような (スコア:0)
CGIやアプリを作れと言われれば作れるけど、あのアクセス数を捌けるだけのものは作れないな
Re: (スコア:0)
今時CGIとか、ここ10年ぐらいの技術に全く付いてこれてないのでは?
Re: (スコア:0)
CGIってただのインターフェイスだよね?
今ではウェブサーバーがCGIでPHPとか他の言語使えたりするけど。
昔の"CGI=Perl"なイメージが強いせいか。
Re:作れるような作れないような (スコア:2)
その頃FacebookはPHPを再実装した。(言いたかっただけ)
Re:作れるような作れないような (スコア:1)
> 今ではウェブサーバーがCGIでPHPとか他の言語使えたりするけど。
PHPは基本的にCGIではないですよ。PHPの言語仕様レベルにウェブサーバへの組み込み機能が含まれており、CGIというインターフェースは使ってません。
(PHPをCGIモードで動かすこともできますけど、今時は滅多に使わないですね。昔はPHP3とPHP4の共存のために、片方はCGIモードで動かすなんてこともやったりしましたけど…)
でもまあ、「ウェブサーバとのインターフェース仕様」としては、CGIがほぼ唯一の存在であることを考えると、
・ウェブサーバとは別に、コンテンツ生成プログラムを動かす方式(≒CGI+PHP)
・コンテンツ生成プログラム自身がサーバとなる方式(Java Servlet、node.js、Ruby on Rails などなど)
という二方式を対比させる感じですかね。
Twitterのような負荷対策が重要なサービスだと、核となる部分は、独自サーバ方式が有力でしょうね。自分なら node.js を選ぶかなぁ。
DBは性能的にKVSにしたいとこですが、フォローした人のツイートの取得とかを考えると、素直にSQLなRDBの方がいいかも。
Re: (スコア:0)
俺はCGI=MVCだな。色々間違ってるのは分かるが・・・
Re: (スコア:0)
俺はCGI=MVCだな。色々間違ってるのは分かるが・・・
???ワークフレームのこと?
Re: (スコア:0)
> CGIってただのインターフェイスだよね?
そもそもCGIが理解できてないですね
CGIは、リクエストが来るたびに、その都度perlなどの別プログラムを子プロセスとして起動する仕組みです。
つまりWebサーバと別プログラム間のインタフェースです
そしてCGIは今となってはセキュリティ的にもパフォーマンス的にも問題ありまくりの方法です
ましてや「あのアクセス数を捌けるだけのもの」という文脈でCGIなんて単語を出すこと自体があり得ません
> 今ではウェブサーバーがCGIでPHPとか他の言語使えたりするけど。
これは完全に誤りです
今では、CGIを使わず、ウェブサーバーのプロセス内部でPHPなどのインタプリタを動かすのが普通です
Re: (スコア:0)
> 今ではウェブサーバーがCGIでPHPとか他の言語使えたりするけど。
> 昔の"CGI=Perl"なイメージが強いせいか。
昔 = 20年前
今 = 15年前
くらいかな?
Re: (スコア:0)
AmazonのLambdaとかぶっちゃけCGIの考え方と同じだと思うのですが
Re: (スコア:0)
昔がっつりはまってたCGIのチャットを思い出します。
私ならLAMPで地道に…というところですが技術に付いてこれてないのかなぁ?
最近もそうかは分かりませんがミクシィもMySQLで運用していると記事で読んだこともありますし、大規模運用でも使えるのかも。
自分ならどうする?と言われれば、アウトラインが分かっている堅実そうな方法になってしまいます。
難しいのは負荷分散のほうでネットワークとサーバーの負荷分散の基本構造が出来れば、あとは回線の太さとサーバーの台数を調整するルーチンワークになるイメージです。
ロードバランサーやデータベースのクラスタリングを駆使すれば足りるのか。。。ちょっとそこは分からないなぁ
Re: (スコア:0)
>CGIやアプリを作れと言われれば作れるけど、あのアクセス数を捌けるだけのものは作れないな
あのアクセス数を捌くのはCGIやアプリの役目ではないです。
Re: (スコア:0)
mod_cgiの再生産、ありがとうございます。