現在最速で最軽量のプログラムの組み合わせはなんだ

1 ：2006/08/06(日)?2BP(0) 〜 最終レス ：2011/11/26(土)?2BP(1960)

実用的でコストも踏まえた最速で最軽量のプログラムの組み合わせを語って欲しい
現在で最速かつ最軽量なプログラムの組み合わせが何かという結論が出ていない
もし実用的でコストが低く纏まるプログラムの組み合わせの結論が出たら、
コストを度外視したプログラムの組み合わせを議論することにします
WEBProg板とWEB製作板のプログラマーの英智を結集してこの問題の結論を出して欲しい
言語はmod_perl(SpeedyCGI FastCGI)とmod_PHP(PHP4 PHP5)とCとJavaなどetc
アプリケーションはApache, CGI, JSP/Servlet, ASP, ColdFusionなどetc
データベースはOracle, PostgreSQL, MySQLなどetc
【アプリケーション】
【データベース】
【言語】
【意見】

2 ：

存分に語って頂きたい

3 ：

つトレードオフ

4 ：

>>３
いきなりかよｗ

5 ：

そもそもドメインスペシフィックだろ.
ネームスペースのないPHPで大規模やる馬鹿はいないし、小規模開発でわざわざJavaを持ち出す必要もないわけで...

6 ：

Kent

7 ：

じゃあ大規模と小規模で分けて最速で最軽量のプログラムの組み合わせを考えていこう
大規模では
【アプリケーション】
【データベース】
【言語】
【意見】
小規模では
【アプリケーション】
【データベース】
【言語】
【意見】

8 ：

そんなこと気にしなくても特定状況でベターな組み合わせってのを適当に列挙すりゃいいんでしょ？
例えばWeb鯖とDB鯖が一緒になってる場合と分けられてる場合だけでも手札は違うんだし。

9 ：

>>1
アプリケーションサーバの選定が無いのは何で。
大規模になれば100％発生する話だが。

10 ：

てか１にも２にも回線でしょ？
って思っちゃう俺は素人。

11 ：

CとOracleだろ

12 ：

ドメインスペシフィック の検索結果 約 354 件中 1 - 10 件目 (0.15 秒)

13 ：

アプリ次第だね。得ろ動画とかなら回線の太さも必要だろうけど
リクエストが多くてアパッチが追いつかない場合も結構ある。

14 ：

＞実用的でコストも踏まえた最速で最軽量のプログラムの組み合わせ
という観点で見た場合
【言語】Perl
【WebServer】Apache2 worker
【AppServer】Apache2 worker/mod_perl2
【DBServer】MySQL5 MyISAM,InnoDB
【意見】
mod_perlは高負荷時に不安定になるので、余裕を持たせたロードバランスをする必要がある。

15 ：

quad cpu+16GBメモリのDBサーバー2台に32TBのストレージシステムぶら下げて
ロードバランシングで6台のサーバーを置き、
回線はハイパー二回線をメインにUSENを八本入れてる。
でもロードバランシング用のPCがセレロンだけど、perlだろうがphpだろうが爆速
まぁ都心の新築ワンルーム買えるぐらいいくけど。

16 ：

"domain specific" の検索結果 約 9,080,000 件中 1 - 10 件目 (0.20 秒)

17 ：

>>14
なるほど、大規模サイトの方での意見はありませんか？

18 ：

良スレにしたければ黙ってる方がいい。

19 ：

>>18
分かりました。ではご自由に議論下さいませ

20 ：

swat

21 ：

質問です。
HTTPリスナーが２つのアクセスを受信したとき、
最軽量というか最も短い時間間隔はどれくらいでしょうか？

22 ：

lighttpd+fastCGI+MySQLはどうよ

23 ：

使える環境ならC/ApacheModuleが現実的だな。
C/CGIはメモリ管理から全部プログラマの責任、しかも遅いがApacheModuleならメモリ管理はApacheがやってくれるし、APIも大量にある。
しかし、mod_phpやmod_perlの速度なら十分だと思う。
共有鯖だとmod_perlは現実的じゃないな

24 ：

NICドライバがHTTPレスポンスを返せばいいじゃまいか

25 ：

CでApacheモジュール書くのが断然速いだろ

26 ：

大量に訪問者がいるタイプの場合は、
アパッチじゃなくてトムキャットの出番だろ
あとは、アセンブラで書くとか炒ってるビギナーは
コンパイラの最適化を知らないんだなきっと。

27 ：

回答ﾖﾛ >>21

28 ：

>>27
お前　質問は質問スレでしろ荒らし、さっさと消え失せろ

29 ：

最軽量の判定基準が >>21 になるんだお。

30 ：

64bitｱｾﾝﾌﾞﾗをちゃんと書けるプログラマがapache、perl、phpの
開発に加わって最適化すれば勝手に速くなるんじゃね？

31 ：

>>30
汎用化したものを利用するとオーバーヘッドが発生するからな。
開発コストを度外視するなら、
コンパイラ以上の最適化を行えるアセンブラ使いが、0から開発した方が速くなる。
LSI作っていいなら、そのほうがより速くなる。

32 ：

大規模の方は意見が出てないな

33 ：

恐らく移植性重視

34 ：

大規模サイトだとmodPHP(PHP5)が有効なのかな？
俺は経験不足なもんで組み合わせが何が良いかが分からない･･･

35 ：

大規模
【言語】J2SE 1.4.2_12
【WebServer】Apache 1.3.37 + mod_jk 1.2.18
【AppServer】JBoss 4.0.4
【DBServer】Oracle10g R2

36 ：

大規模　ＪＡ
中小器　ＰＨＰ、ＰＥＲＬ
生産性　ＰＨＰ・ＰＥＲＬ＞ＪＡ
分散機能　ＪＡ＞ＰＨＰと聞いたことがあります

37 ：

大規模と小規模ってそれぞれどれぐらいなんでしょうか？
HIT数で決めるんですよね？そうだとすると2chは大規模サイトなの？

38 ：

>>37
機能的に、でしょ。
2chは小規模なプログラムの集合体だし。

39 ：

>>26
> アパッチじゃなくてトムキャットの出番だろ
ベンチ取ったら自分が間違ってるって分かるよ。。。

40 ：

2chって小規模なプログラムの集合体なんだ
掲示板だけじゃないの？それに良く落ちるけどmod perlだから？

41 ：

日本における大規模(w
【言語】Java
【WebServer】FJApache
【AppServer】Interstage Application Server
【DBServer】Symfoware
【言語】Java
【WebServer】HitachiWebServer
【AppServer】uCosminexus Application Server
【DBServer】HiRDB

42 ：

>>40
mod_perlではない

43 ：

ところで>>35>>41じゃどっちが最速最軽量なのか、俺はJava詳しく無いから知らん

44 ：

>>42
mod_perlじゃなかったの？PHPで書かれている部分があるのは知ってたけど

45 ：

>>44
こんなページあった
ttp://sunos.saita.ma/2ch-cgi-lw.html

46 ：

大規模と小規模に意見が出たがプログラマーの皆はこれが最速最軽量ローコストで納得なのか？

47 ：

別にどーでもいい。決めたところですぐに次が出てくるし。

48 ：

コーディング次第で速くも遅くもなるのでチームの手腕次第でFA

49 ：

軽量ではないがRailsに一票

50 ：

だからハードウェアプログラミングだと何回言わせたら(ry

51 ：

>>44
read.cgi
C言語、JavaScript+Apache Module化実験中
bbs.cgi
Perl(SpeedyCGI)、Apache Module(C言語)
携帯用
PHP

52 ：

実装を問わず、アプリケーションロジックの深い所に入ったりRDBMS等に
アクセスが発生するとどうしても重くなるわけで。。。
と言うわけで、どのようにキャッシュの実装を行うかという所がミソだと思う。

53 ：

キャッシュは論理的実装だからスレ違いじゃないか。

54 ：

大規模、小規模ってアクセス数とかの話しじゃなくて、プログラム規模
(ステップ数、工数等)で決めるって事だよね？
数千万ステップ級から100ステップ程度の入力フォームまで
色々あるわけだが、どのぐらいと考えるべきなんでしょかね？
10万ステップ級、100万ステップ級とかでも判断が分かれてくるかも知れない。
また、バックエンドの処理が複雑な分散トランザクションが中心となる物も
あるし、数値科学演算がメインの処理系もある。フロントエンドだけやけに
複雑だけど、バックエンドは単純な物もある。
なかなかひっくるめて判断するのは難しいな。
例えばヤフオクの最適解は何か、mixiの最適解は何かとか、そんな感じの
方が真面目に議論できるような気がする。

55 ：

>54のせいでクソスレ確定
そして糸冬 了

56 ：

>>54
それだったら、Googleみたいにコンピュータアーキテクチャから考え直したほうがいい。

57 ：

>Googleみたいにコンピュータアーキテクチャ
？
Google ってコンピュータとぽしては汎用の x86 を使ってるじゃないんですか？
ラックだとか電源だとかはコンピュータアーキテクチャと言わないだろうし...

58 ：

>>57
こういうことでしょ。
http://dev.ariel-networks.com/modules/xfsection/article.php?articleid=50

59 ：

一番上に
>安いPC(OSはGNU/Linux)で
って書いてあるじゃん．

60 ：

小規模はperlでSpeedyCGIかCがバランス的にベストって感じ？
モジュールで動くphpはSpeedyCGIのperlよりは遅いんだよな。

61 ：

x86と汎用って単語を結びつける人もいるんだね。
ところで、俺は前振りなしで「コンピュータアーキテクチャ」って言われたら、
最近のRISCはロード／ストアアーキテクチャを指して、縮小命令セット
の意味は無くなってきたよね、とかいう方を思い浮かべる。

62 ：

だれもお前のバカな考えは聞いていない。
つまらん一人語りする前にスレタイトルを読み直せ。

63 ：

>>1を読む限りJazelle対応のARMをコネクションマシンのように並べたサーバ
にしてみようか、とかってのはアリだと思うが。

64 ：

>>61は意味を自分の分野で使われる意味でしか汎用をいう言葉をとらえていない気がする。
組み込みからＰＣそしてスーパコンピュータまでカバーするアーキテクチャを汎用と呼ぶのはなにもおかしくない。
こういう専門バカにはなりたくないな

65 ：

>>63
知ってる単語を並べるのはいいが、何年か前にあれほど騒がれたＪａｖａプロセッサが未だにくすぶってる理由考えたことある？

66 ：

>組み込みからＰＣそしてスーパコンピュータまでカバーするアーキテクチャ
x86が？
>>65
>知ってる単語を並べるのはいいが、何年か前にあれほど騒がれたＪａｖａプロセッサが未だにくすぶってる理由考えたことある？
まぁまぁ、思考停止してないで、ちょっと想像してみそ。
粒度の小さいオブジェクトを分散処理させるのにどんなやりかたがあるか。

67 ：

>x86が？
Ｙｅｓ
スーパーコンピュータについてはこの辺参照。
http://grape.astron.s.u-tokyo.ac.jp/~makino/articles/future_sc/face.html
>粒度の小さいオブジェクトを分散処理させるのにどんなやりかたがあるか。
思考停止とかをせずに考えた結果が
>Jazelle対応のARMをコネクションマシン
ですか？思考停止うんぬんの前にＷｅｂアプリの性質を洗い直すことをおすすめしますよ。
マジで。

68 ：

>スーパーコンピュータについてはこの辺参照。
ううむ、少なくともどんなプロセッサでもたくさんつなげばスーパーコンピュータになっちゃうよ
っていう意味ではx86は価格性能比でアドバンテージがあると書いてあるようだ。
けど、これFPGAまで出てきてるね、この世に汎用でないプロセッサは無いって感じだ。
これ、読み物としては面白いので、２４見終わったらじっくり呼んでみるよありがとう。
>考えた結果が
結論だとも、それが良さそうだとも言ってない。
考えてみる価値はありそうだ、とは思ってるしそのくらいのニュアンスで書いたんだが、
言葉の選び方がまずかったかな？
てか、いまとりあえずARM926EJ-Sコアのの乗ったボード２台でそのあたりの実験の準備中。
そうそう
>Ｗｅｂアプリの性質洗い直すことをおすすめしますよ
リクエストが来たら処理して結果を返す部分だけがシステムじゃないし。

69 ：

ご主人様がいらっしゃる！！
うほっ！！

70 ：

>っていう意味ではx86は価格性能比でアドバンテージがあると書いてあるようだ。
そう。その結果、アーキテクチャとしてどうだ、とか言う話は置いておいて現時点でもっとも汎用的なアーキテクチャの一つになっちゃったわけ。
>この世に汎用でないプロセッサは無いって感じだ。
？なんか話ずれてる気が。
>リクエストが来たら処理して結果を返す部分だけがシステムじゃないし。
なら
>Jazelle対応のARMをコネクションマシンのように並べたサーバ
にはどのあたりの処理を担わせることをねらってるんでしょうか？

71 ：

>少なくともどんなプロセッサでもたくさんつなげばスーパーコンピュータになっちゃうよ
ここ間違ってるとおもう。量が増えるとつなぐのも結構難しい。

72 ：

>ここ間違ってるとおもう。量が増えるとつなぐのも結構難しい。
ハイパーキューブなら自分と周辺４つがつながれば良いしな、とか
簡単に考えてたよ。
ちょっと簡単に考え過ぎたかも。ごめん。
件のページにそんなことも書いてあるのかな？
ま、あとで読んでみます。

73 ：

>>70
>現時点でもっとも汎用的なアーキテクチャの一つになっちゃったわけ。
うん、そういう意味での汎用性なら、よくわかる。
もともとが、汎用って言ったらプロセッサはx86に限らず汎用でないの？
って意味でも突っ込みだったし（←思い出したらしい）
>>Jazelle対応のARMをコネクションマシンのように並べたサーバ
>にはどのあたりの処理を担わせることをねらってるんでしょうか？
具体的な用途はまだまだずっと先に考えるのかな、と前置きして、
つなげるところまで行けたらまずシミュレーションゲームのいわゆる思考ルーチン
でいろいろ試してみたいなと思ってる。
分散処理のメリットがあるのか？とかいう突っ込みはあるだろうけど。

74 ：

ハードウェアが HTTP レスポンスを返すソリューションならすべてが高速
汎用PCは必須ではねぇんじゃね？

75 ：

おまえらとにかくスレ違いだ、他でやれ

76 ：

何処がすれ違いなのか意味不明。単にお前が理解できてないだけじゃね？

77 ：

いや、そう言ってみたいお年頃なんだろう。

78 ：

ご主人様の肛門も４辺で接続されそうです。

79 ：

こういうの「ご主人様」って言うですか？

80 ：

>>76
>>1は読んだのか?

81 ：

ご主人様！ご主人様！ご主人様！

82 ：

「汎用の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 ：

>そこそこのパフォーマンスが出て、開発コストと規模とのバランスが取れる
>アーキテクチャを考えるってのは必要だろうね。
何かを言ってるようで実は中身は空っぽな発言するやつっているよね

84 ：

具体例を挙げたつもりだったんだけどな。

85 ：

>>83
理解出来ないからといって、見えなくなるのはどうかと思う

86 ：

なんか伸びてると思ったら...
>汎用の x86 PC（汎用は PC にかかる）
と書けば良かったのかな．

87 ：

>>１
なにもしない事。
間違ってもプログラムなんて書かないこと。

88 ：

いきなりプログラムの組み合わせって言われてもなにをする目的なのか・・
ま、Webプログラムだろうけど目的も書かないでいきなり組み合わせを聞かれても

89 ：

目的：最速、最軽量

90 ：

だからどの分野でだって聞いてるんだヴァカ

91 ：

日本語が理解出来ないのか？
目的には分野などは入っていない。

92 ：

ブルージニー使えば爆速
組み合わせなんか適当でええやん

93 ：

>>90
ベクトル計算

94 ：

どう考えてもcoldfusionが最速
ﾊｧﾊｧ

95 ：

ﾔﾌｵｸに↓の中古が出てけど、Pentium4 3.06GHzとの比較って今ではどんぐらい？
ttp://v-t.jp/jp/topics/press/030401/

96 ：

HTMLとJavaScriptの組み合わせが一番最強

97 ：

Flashじゃダメ？

98 ：

Flashは待ち時間が長すぎる

99 ：

>>96
JavaScriptは強いな

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 削除依頼 ▲
・　次のスレ
【勉強するのは】PHPとPerl【どっちが最初？】
WEB開発環境「葵」スレ
FreeStyleWikiスレ
第二回 自作スクリプト発表会【PHP】