アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
APサーバの構成 (スコア:0)
一台あたりのCPU数は同じで、台数をN倍にした方がより高速になるというのが
一般的な答ではないでしょうか？ もちろん、実メモリ不足のような状況に
陥ってないということが前提ですが…
ですから、
> 楽天の2CPUクラスのエントリーモデルのシステムをいくら増やしても取引の
> 急増に対処できない
という部分は納得がいかないのですが…
私が何か勘違いしている点があるでしょうか？
Re:APサーバの構成 (スコア:1)
しかし、大量のクライアントからの要求を処理するシステムだと、大量にメモリーを搭載したAPサーバのメモリ上にservantをすべて展開するとか、大量のCPUを積んだAPサーバにマルチスレッドでservantが稼動してメソッドを個別に呼び出すとか無茶な仕様になっていて、実装方法が不適切なままスケールアウトすると、性能がかなり落ちることは珍しくないと思います
それに、ローエンドサーバと、ミッドエンジサーバのメモリ性能やバス調停性能の差はかなり大きいと思います。N個CPU=N台には必ずしもならないと思ったりするんですが、いかがでしょう？
Re:APサーバの構成 (スコア:0)
> にメモリーを搭載したAPサーバのメモリ上にservantをすべて展開する
> とか、
物理メモリから溢れないというのは大前提です。
このため、CPUの少ない構成であっても、必要なだけのメモリは積む
必要があります。スケールアウトした場合の方が、システム全体を
トータルした必要メモリ容量は大きくなるのが普通だと思います。
逆に、そうやって、物理メモリから溢れないだけの容量を確保すれば、
特に問題はないはずです。
> 大量のCPUを積んだAPサーバにマルチスレッドで servantが稼動してメ
> ソッドを個
Re:APサーバの構成 (スコア:1)
一応それは踏まえた上で書いてます
DLJ時代に構築されたシステムは、Web、Marketspeed(TCP/UDP)、コールセンター系(CTI)、imode系Webのトランザクションを一元的に処理するために、ミッドエンジクラスのサーバを前提にCORBAでシステムが構築されています。買収後の04年から05年にかけて、このシステムをスケールアウトしてエントリーモデルのサーバに置き換えていますが、この更新時の実装方法が不適切だったのではないのかというのが趣旨です
Re:APサーバの構成 (スコア:0)
CORBAを使う場合も、トランザクション処理はバックエンドのデータベース
サーバ側に分離するので、フロントエンドにあるアプリケーションサーバ
に関しては容易にスケールアウト可能になる… というのが典型的な構成
ではないかと思うのですが、そうではなく、アプリケーションサーバを
動かすフロントエンドのマシンでも、データベースの一部を持っていると
いうことでしょうか？ アプリケーションサーバとデータベースサーバは
別プロセスですから、サーバ構成を変更する場合には、データベースだけ、
バックエンドの強力なマシンに移動することは容易だと思うのですが…
典型的ではない構成をとっている場合には、その旨、書き添えておかない
と、私のように疑問に感じる人が出てくるように思います。