Groove Labo
  • Home
  • About

カテゴリー

  • Active Directory (1)
  • FastCGI (2)
  • IIS (2)
  • javascript (5)
  • kickstart (1)
  • MySQL (3)
  • PHP (2)
    • CakePHP (1)
  • postfix (1)
  • Python (7)
  • Ruby on Rails (3)
  • Trac (5)
  • Webサーバー (4)
    • Apache (2)
    • lighttpd (1)
    • pound (1)
    • proxy (1)
  • はじめまして (1)
  • サーバーインフラ (6)
    • Amazon EC2 (2)
    • ZABBIX (3)
  • ソフトウェア開発 (12)
    • テスト (4)
  • ツール (9)
    • backup (1)
    • capistrano (1)
    • CMS (2)
    • couchdb (2)
    • MODx (2)
    • rsync (1)
    • tiddlywiki (1)
    • Wiki (2)
  • デザイン (1)
  • プロジェクト管理 (7)
  • 仮想環境 (5)
    • EC2 (1)
    • VMware (1)
    • Xen (3)
  • 読書 (3)

最近の投稿

  • Railsのdatetime_selectの保存の仕組みを調べてみる
  • [メモ] CentOS5 にkeepalived を設定する
  • ドッグフードを食べる – BTS & SCM
  • CakePHP で連結テーブルのモデルは先に宣言すること
  • ActiveRecord の conditions を作成するためのクラスを作ってみた

Twitter

  • blog: Trac : プラグイン一覧 http://blog.ciklone.com/2010/08/15/trac-%e3%83%97%e3%83%a9%e3%82%b0%e3%82%a4%e3%83%b3%e4%b8%80%e8%a6%a7/ 2010-08-25
  • blog: Trac プラグイン : Awesome Attachments Plugin http://bit.ly/aR3AXc 2010-08-25
  • blog: 機能紹介「ダッシュボード」 http://bit.ly/csA7pU 2010-07-01
  • More updates...

Powered by Twitter Tools

ブログロール

  • Cubo
  • OpenGroove
  • zeera document search
  • zeera document search 診断
負荷試験の考え方(お客様へ説明すべきこと)
投稿日 2009年8月17日 月曜日 カテゴリ Apache, ソフトウェア開発, テスト 投稿者 syojiコメントは受け付けていません。 

Webアプリケーションやクライアントサーバ型のシステム開発の中で性能要件を満たすために負荷試験やロード試験といわれる工程がある。

重要な工程として考えているが、スケジュールの厳しいプロジェクトなどでは後回しにされることがあった。 特に、開発が遅れている場合、要件を満たすための開発が重視されることは理解しているが、負荷試験を実施することは同じくらい大切な工程である。試験で起こることは当然、本番環境でも起こり、あとで痛い目をみないためにも必須の工程である。

負荷試験を設計する上での考え方をまとめてみたいと思う。 以下のサイトが参考になる。

  • 理論的・計画的なWebアプリケーションのテストの実現:第4回 テストを設計するには(その2) (1/2) – ITmedia エンタープライズ

負荷試験とは

構築するシステムがどの程度の負荷に耐えられるかを測定し、システムの信頼性と耐用範囲を明確にする。ウェブアプリケーションの場合、同時アクセスユーザ数をどれだけ処理出来るか、閾値を越えた場合のシステムの振る舞いを検証する試験である。

負荷試験で使われる試験環境は本番環境と同一であることが望ましい。しかし、実際には機器調達が難しいことが多い(例えば、想定している分だけのクライアントマシンを用意する等)。機器が準備できない場合、サーバに負荷を発生させるツール等を使用し、高負荷、過負荷を与え、システムの振舞いについて検証する。

負荷試験の計画(設計)に必要なこと 負荷試験を計画するときに最低限、考えなければいけないことを説明したい。

前提条件

試験を実施するときの試験環境について、サーバの役割、台数、クライアント数、負荷をかける時間等の環境について条件を明確化しておく必要がある。

監視ポイント

例えば、Webアプリケーションの場合、クライアントがアクセスしトップページが表示されるまでの時間。など要件を満たすために必要な監視ポイントを明確にしておく必要がある。サーバサイドではDBに対する大量のI/O(書込、読み出し等)がそれにあたると思われる。

目的と対象範囲

負荷試験でクリアしなければいけない要件、ユーザ数などの試験の目的と対象範囲/ハード情報(各サーバのOS情報/CPU/DISK IO/MEMORY/NETWORK)、過負荷時の測定範囲を明確にする。

性能要件(目標値)

想定されるクライアント数から性能要件を予測し、定義する。レスポンス時間等の試験項目から測定可能な数値を予測する。 例えば年に1度のみ過負荷が発生するといった事象に合わせてシステムを組んだ場合、性能要件は十分であるが、コスト面で満足するものにはならない場合がある。そのため、要件にあった目標値を設定することは重要である。

想定シナリオ

構築するシステムの利用シーンを考えたシナリオを作成する。試験実施はそのシナリオに沿って行われるべきである。 例えば、メールクライアントの場合、社員が出社する時間(09:00頃)が大量のアクセスが発生する、など。その利用シーンをシナリオに組み込む。

実施方法

市販のツールを利用する、自作ツールを利用する、など目標値を達成するためには過負荷状態を作らなければいけない。疑似的に過負荷状態を作り出す必要がある。Webアプリケーションに限定されるが無料ですばらしいツールが多く提供されている。

  • @IT:JMeterによるWebサーバ性能評価の勘所(1/3)
  • The Jakarta Site – The Jakarta Project — Java Related Products
  • JMeter(高機能/フリーなテストツール)第1回:JMeterの基本

試験結果

負荷試験計画時の「目的と対象範囲」を達成したかどうか、 実測値が予測値より悪い場合や、目標値ギリギリの場合、チューニングを実施することになる。 問題点の原因については、計測データなどを使って

  • トランザクション数/クライアント数が増加しているとき、スループットの増加傾向が変化した時点
  • レスポンスタイムが急速に遅くなった点

分析するポイントとして、システムの測定値が急激に変化したとき、関連するモジュールがボトルネックと考えられる。 チューニングについては、そのようなボトルネックと予測されるモジュールから優先的に検証する必要がある。

以上のような点について、負荷試験の計画フェーズで考えておけば良いのではないかと考える。 負荷試験が実施されるのはシステムが構築され、結合試験も終わった以降になる。一番忙しいフェーズであるが 負荷試験の重要性を説明し、しっかりと計画をして実施していきたいと思う。

Comments are closed.

Copyright © 2004-2010 OpenGroove,Inc. All rights reserved.