現在最速で最軽量のプログラムの組み合わせはなんだ
実用的でコストも踏まえた最速で最軽量のプログラムの組み合わせを語って欲しい
現在で最速かつ最軽量なプログラムの組み合わせが何かという結論が出ていない
もし実用的でコストが低く纏まるプログラムの組み合わせの結論が出たら、
コストを度外視したプログラムの組み合わせを議論することにします
WEBProg板とWEB製作板のプログラマーの英智を結集してこの問題の結論を出して欲しい
言語はmod_perl(SpeedyCGI FastCGI)とmod_PHP(PHP4 PHP5)とCとJavaなどetc
アプリケーションはApache, CGI, JSP/Servlet, ASP, ColdFusionなどetc
データベースはOracle, PostgreSQL, MySQLなどetc
【アプリケーション】
【データベース】
【言語】
【意見】 そもそもドメインスペシフィックだろ.
ネームスペースのないPHPで大規模やる馬鹿はいないし、小規模開発でわざわざJavaを持ち出す必要もないわけで... じゃあ大規模と小規模で分けて最速で最軽量のプログラムの組み合わせを考えていこう
大規模では
【アプリケーション】
【データベース】
【言語】
【意見】
小規模では
【アプリケーション】
【データベース】
【言語】
【意見】 そんなこと気にしなくても特定状況でベターな組み合わせってのを適当に列挙すりゃいいんでしょ?
例えばWeb鯖とDB鯖が一緒になってる場合と分けられてる場合だけでも手札は違うんだし。 >>1
アプリケーションサーバの選定が無いのは何で。
大規模になれば100%発生する話だが。 てか1にも2にも回線でしょ?
って思っちゃう俺は素人。 ドメインスペシフィック の検索結果 約 354 件中 1 - 10 件目 (0.15 秒) アプリ次第だね。得ろ動画とかなら回線の太さも必要だろうけど
リクエストが多くてアパッチが追いつかない場合も結構ある。 >実用的でコストも踏まえた最速で最軽量のプログラムの組み合わせ
という観点で見た場合
【言語】Perl
【WebServer】Apache2 worker
【AppServer】Apache2 worker/mod_perl2
【DBServer】MySQL5 MyISAM,InnoDB
【意見】
mod_perlは高負荷時に不安定になるので、余裕を持たせたロードバランスをする必要がある。
quad cpu+16GBメモリのDBサーバー2台に32TBのストレージシステムぶら下げて
ロードバランシングで6台のサーバーを置き、
回線はハイパー二回線をメインにUSENを八本入れてる。
でもロードバランシング用のPCがセレロンだけど、perlだろうがphpだろうが爆速
まぁ都心の新築ワンルーム買えるぐらいいくけど。
"domain specific" の検索結果 約 9,080,000 件中 1 - 10 件目 (0.20 秒) >>14
なるほど、大規模サイトの方での意見はありませんか? >>18
分かりました。ではご自由に議論下さいませ 質問です。
HTTPリスナーが2つのアクセスを受信したとき、
最軽量というか最も短い時間間隔はどれくらいでしょうか? lighttpd+fastCGI+MySQLはどうよ 使える環境ならC/ApacheModuleが現実的だな。
C/CGIはメモリ管理から全部プログラマの責任、しかも遅いがApacheModuleならメモリ管理はApacheがやってくれるし、APIも大量にある。
しかし、mod_phpやmod_perlの速度なら十分だと思う。
共有鯖だとmod_perlは現実的じゃないな NICドライバがHTTPレスポンスを返せばいいじゃまいか 大量に訪問者がいるタイプの場合は、
アパッチじゃなくてトムキャットの出番だろ
あとは、アセンブラで書くとか炒ってるビギナーは
コンパイラの最適化を知らないんだなきっと。 >>27
お前死ね 質問は質問スレでしろ荒らし、さっさと消え失せろ 64bitアセンブラをちゃんと書けるプログラマがapache、perl、phpの
開発に加わって最適化すれば勝手に速くなるんじゃね? >>30
汎用化したものを利用するとオーバーヘッドが発生するからな。
開発コストを度外視するなら、
コンパイラ以上の最適化を行えるアセンブラ使いが、0から開発した方が速くなる。
LSI作っていいなら、そのほうがより速くなる。 大規模サイトだとmodPHP(PHP5)が有効なのかな?
俺は経験不足なもんで組み合わせが何が良いかが分からない・・・ 大規模
【言語】J2SE 1.4.2_12
【WebServer】Apache 1.3.37 + mod_jk 1.2.18
【AppServer】JBoss 4.0.4
【DBServer】Oracle10g R2 大規模 JAVA
中小器 PHP、PERL
生産性 PHP・PERL>JAVA
分散機能 JAVA>PHPと聞いたことがあります 大規模と小規模ってそれぞれどれぐらいなんでしょうか?
HIT数で決めるんですよね?そうだとすると2chは大規模サイトなの? >>37
機能的に、でしょ。
2chは小規模なプログラムの集合体だし。 >>26
> アパッチじゃなくてトムキャットの出番だろ
ベンチ取ったら自分が間違ってるって分かるよ。。。 2chって小規模なプログラムの集合体なんだ
掲示板だけじゃないの?それに良く落ちるけどmod perlだから? 日本における大規模(w
【言語】Java
【WebServer】FJApache
【AppServer】Interstage Application Server
【DBServer】Symfoware
【言語】Java
【WebServer】HitachiWebServer
【AppServer】uCosminexus Application Server
【DBServer】HiRDB ところで>>35>>41じゃどっちが最速最軽量なのか、俺はJava詳しく無いから知らん >>42
mod_perlじゃなかったの?PHPで書かれている部分があるのは知ってたけど
>>44
こんなページあった
ttp://sunos.saita.ma/2ch-cgi-lw.html 大規模と小規模に意見が出たがプログラマーの皆はこれが最速最軽量ローコストで納得なのか? 別にどーでもいい。決めたところですぐに次が出てくるし。 コーディング次第で速くも遅くもなるのでチームの手腕次第でFA だからハードウェアプログラミングだと何回言わせたら(ry >>44
read.cgi
C言語、JavaScript+Apache Module化実験中
bbs.cgi
Perl(SpeedyCGI)、Apache Module(C言語)
携帯用
PHP 実装を問わず、アプリケーションロジックの深い所に入ったりRDBMS等に
アクセスが発生するとどうしても重くなるわけで。。。
と言うわけで、どのようにキャッシュの実装を行うかという所がミソだと思う。 大規模、小規模ってアクセス数とかの話しじゃなくて、プログラム規模
(ステップ数、工数等)で決めるって事だよね?
数千万ステップ級から100ステップ程度の入力フォームまで
色々あるわけだが、どのぐらいと考えるべきなんでしょかね?
10万ステップ級、100万ステップ級とかでも判断が分かれてくるかも知れない。
また、バックエンドの処理が複雑な分散トランザクションが中心となる物も
あるし、数値科学演算がメインの処理系もある。フロントエンドだけやけに
複雑だけど、バックエンドは単純な物もある。
なかなかひっくるめて判断するのは難しいな。
例えばヤフオクの最適解は何か、mixiの最適解は何かとか、そんな感じの
方が真面目に議論できるような気がする。
>>54
それだったら、Googleみたいにコンピュータアーキテクチャから考え直したほうがいい。 >Googleみたいにコンピュータアーキテクチャ
?
Google ってコンピュータとぽしては汎用の x86 を使ってるじゃないんですか?
ラックだとか電源だとかはコンピュータアーキテクチャと言わないだろうし... 一番上に
>安いPC(OSはGNU/Linux)で
って書いてあるじゃん. 小規模はperlでSpeedyCGIかCがバランス的にベストって感じ?
モジュールで動くphpはSpeedyCGIのperlよりは遅いんだよな。 x86と汎用って単語を結びつける人もいるんだね。
ところで、俺は前振りなしで「コンピュータアーキテクチャ」って言われたら、
最近のRISCはロード/ストアアーキテクチャを指して、縮小命令セット
の意味は無くなってきたよね、とかいう方を思い浮かべる。
だれもお前のバカな考えは聞いていない。
つまらん一人語りする前にスレタイトルを読み直せ。 >>1を読む限りJazelle対応のARMをコネクションマシンのように並べたサーバ
にしてみようか、とかってのはアリだと思うが。 >>61は意味を自分の分野で使われる意味でしか汎用をいう言葉をとらえていない気がする。
組み込みからPCそしてスーパコンピュータまでカバーするアーキテクチャを汎用と呼ぶのはなにもおかしくない。
こういう専門バカにはなりたくないな >>63
知ってる単語を並べるのはいいが、何年か前にあれほど騒がれたJavaプロセッサが未だにくすぶってる理由考えたことある? >組み込みからPCそしてスーパコンピュータまでカバーするアーキテクチャ
x86が?
>>65
>知ってる単語を並べるのはいいが、何年か前にあれほど騒がれたJavaプロセッサが未だにくすぶってる理由考えたことある?
まぁまぁ、思考停止してないで、ちょっと想像してみそ。
粒度の小さいオブジェクトを分散処理させるのにどんなやりかたがあるか。 >x86が?
Yes
スーパーコンピュータについてはこの辺参照。
http://grape.astron.s.u-tokyo.ac.jp/~makino/articles/future_sc/face.html
>粒度の小さいオブジェクトを分散処理させるのにどんなやりかたがあるか。
思考停止とかをせずに考えた結果が
>Jazelle対応のARMをコネクションマシン
ですか?思考停止うんぬんの前にWebアプリの性質を洗い直すことをおすすめしますよ。
マジで。 >スーパーコンピュータについてはこの辺参照。
ううむ、少なくともどんなプロセッサでもたくさんつなげばスーパーコンピュータになっちゃうよ
っていう意味ではx86は価格性能比でアドバンテージがあると書いてあるようだ。
けど、これFPGAまで出てきてるね、この世に汎用でないプロセッサは無いって感じだ。
これ、読み物としては面白いので、24見終わったらじっくり呼んでみるよありがとう。
>考えた結果が
結論だとも、それが良さそうだとも言ってない。
考えてみる価値はありそうだ、とは思ってるしそのくらいのニュアンスで書いたんだが、
言葉の選び方がまずかったかな?
てか、いまとりあえずARM926EJ-Sコアのの乗ったボード2台でそのあたりの実験の準備中。
そうそう
>Webアプリの性質洗い直すことをおすすめしますよ
リクエストが来たら処理して結果を返す部分だけがシステムじゃないし。 >っていう意味ではx86は価格性能比でアドバンテージがあると書いてあるようだ。
そう。その結果、アーキテクチャとしてどうだ、とか言う話は置いておいて現時点でもっとも汎用的なアーキテクチャの一つになっちゃったわけ。
>この世に汎用でないプロセッサは無いって感じだ。
?なんか話ずれてる気が。
>リクエストが来たら処理して結果を返す部分だけがシステムじゃないし。
なら
>Jazelle対応のARMをコネクションマシンのように並べたサーバ
にはどのあたりの処理を担わせることをねらってるんでしょうか? >少なくともどんなプロセッサでもたくさんつなげばスーパーコンピュータになっちゃうよ
ここ間違ってるとおもう。量が増えるとつなぐのも結構難しい。 >ここ間違ってるとおもう。量が増えるとつなぐのも結構難しい。
ハイパーキューブなら自分と周辺4つがつながれば良いしな、とか
簡単に考えてたよ。
ちょっと簡単に考え過ぎたかも。ごめん。
件のページにそんなことも書いてあるのかな?
ま、あとで読んでみます。 >>70
>現時点でもっとも汎用的なアーキテクチャの一つになっちゃったわけ。
うん、そういう意味での汎用性なら、よくわかる。
もともとが、汎用って言ったらプロセッサはx86に限らず汎用でないの?
って意味でも突っ込みだったし(←思い出したらしい)
>>Jazelle対応のARMをコネクションマシンのように並べたサーバ
>にはどのあたりの処理を担わせることをねらってるんでしょうか?
具体的な用途はまだまだずっと先に考えるのかな、と前置きして、
つなげるところまで行けたらまずシミュレーションゲームのいわゆる思考ルーチン
でいろいろ試してみたいなと思ってる。
分散処理のメリットがあるのか?とかいう突っ込みはあるだろうけど。 ハードウェアが HTTP レスポンスを返すソリューションならすべてが高速
汎用PCは必須ではねぇんじゃね? 何処がすれ違いなのか意味不明。単にお前が理解できてないだけじゃね? 「汎用のx86」は間違ってないけど「人力の自転車」みたいなこそばゆさを感じる。
68KだってPPCだって、それこそ4004だって、それぞれの視点で「汎用」じゃん。
話は戻るけど、
>>54
>例えばヤフオクの最適解は何か、mixiの最適解は何かとか、そんな感じの
>方が真面目に議論できるような気がする。
>>56
>それだったら、Googleみたいにコンピュータアーキテクチャから考え直したほうがいい。
↓これを思い出した。
普通のやつらの上を行け ---Beating the Averages---
http://www.shiro.dreamhost.com/scheme/trans/beating-the-averages-j.html
本筋ではないけど、Yahoo StoreにLispが使われてる話がチラッと出てくる。
あと、ページ遷移をschemeの継続を使って書いてあるって話は、googleだっけ?
この文脈で「アーキテクチャ」って言ったら、このへんの事だろうな。
言うんだった、ソフトウエアアーキテクチャとか、システムアーキテクチャの方が近いだろう。
そこそこのパフォーマンスが出て、開発コストと規模とのバランスが取れる
アーキテクチャを考えるってのは必要だろうね。
>そこそこのパフォーマンスが出て、開発コストと規模とのバランスが取れる
>アーキテクチャを考えるってのは必要だろうね。
何かを言ってるようで実は中身は空っぽな発言するやつっているよね >>83
理解出来ないからといって、見えなくなるのはどうかと思う
なんか伸びてると思ったら...
>汎用の x86 PC(汎用は PC にかかる)
と書けば良かったのかな. >>1
なにもしない事。
間違ってもプログラムなんて書かないこと。 いきなりプログラムの組み合わせって言われてもなにをする目的なのか・・
ま、Webプログラムだろうけど目的も書かないでいきなり組み合わせを聞かれても 日本語が理解出来ないのか?
目的には分野などは入っていない。 ブルージニー使えば爆速
組み合わせなんか適当でええやん ヤフオクに↓の中古が出てけど、Pentium4 3.06GHzとの比較って今ではどんぐらい?
ttp://v-t.jp/jp/topics/press/030401/ HTMLとJavaScriptの組み合わせが一番最強 >>99
基本的なとこだけサーバーサイドでやって、
あとはクライアントサイドに任せるのが一番速いのさ。