第4回 キャパシティ改善 【対策立案フェーズ 2】 | gihyo.jp
図2から、キャパシティ改善前では、DBサーバのCPU使用率が70%の状態で、24,000リクエスト／5分間を処理できていることがわかります。そして、キャパシティ改善後には、同じCPU使用率で36,000リクエスト／5分間を処理できるようにすれば目標達成です。ですので、単純に、36,000÷24,000＝1.5倍の性能を持つサーバにリプレースしてあげれば良いことがわかります。 仮に現在のサーバのベンチマーク値を「10」だとすると、10×1.5＝15ですので、「15」のベンチマーク値をもつサーバにリプレースしてあげればよいことがわかります。このように、ベンチマーク値から適切なサーバを割り出すことが可能です。 ここで問題になってくるのが、どのベンチマーク値を使用するかです。上で説明したとおり、世の中にはさまざまなベンチマーク結果が存在します。今回の例である「せいのう.jp」はオンラインショッピ
ハード性能以上の性能は出ないんです
こうした考え方に沿うと、性能要件として、ユーザー数やデータ件数しか記載されていない場合は、条件が不足していることになります。例えば「ユーザー100人が同時にアクセスしても問題なく利用できるシステム」というのは、一見すると性能要件としてもっともらしいのですが、実際にはユーザーの操作の内容や頻度によって、求められるハードウェアはまったく異なってくるのです。 また、性能要件が業務量の見込みの値を前提としている点にも注意が必要です。社内システムのような利用者が限定されているシステムでさえ、、見込みと現実が完全に一致するというのはまれなケースでしょう。業務量が想定どおりにならない可能性に備えておくことこそ、プロアクティブな性能管理といえます。 2）性能要件とIT基盤要件の関係を把握する 性能要件が決まれば、その条件を満たすハードウェアスペックを求めていきます。性能要件と同様、これもまた不確実さを伴う
システム基盤設計の基礎
交通量に見合った道路を作ったり，工場の排煙を減らす高度なごみ処理施設を建設したりする，といった基本的な都市計画がなされていない，つまり「都市基盤」が整備されていなければどうなるか。道路は慢性的に渋滞しており，たどりつくだけで一苦労。街で交通事故が発生しても救急車が現場に到達することさえままならない。工場は排煙をまき散らし，深刻な大気汚染を引き起こす──。 情報システムにも，同じことが当てはまる。豊富な機能を持つアプリケーションを開発することは確かに重要だ。だが，サーバーやストレージの性能や信頼性，ネットワークの回線速度などを無視していては，システムの品質を保つことは難しい。システム開発に携わるあらゆるITエンジニアにとって，システムの性能や信頼性などを左右する「システム基盤」の知識は不可欠だ。そこで本講座では，システム基盤を理解するための基本的な技術や用語から，実践的な開発方法論までを解説
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
リサーチ＆アクティビティ | NTT R&D Website
