この記事は、はてなエンジニアアドベントカレンダー2016の12月18日の記事です。 はてなエンジニアアドベントカレンダー2016を始めます - Hatena Developer Blog 昨日はid:ikesyoさんの「オープンソース活動への取り組み方」でした。 オープンソース活動への取り組み方 - Hatena Developer Blog こんにちは。はてなでWebオペレーションエンジニアとして働いているid:taketo957です。 2016年の4月に新卒として入社してからは、社内の仮想化基盤のリソース最適化に取り組んでみたり、 speakerdeck.com 社内の広告配信システムの刷新プロジェクトに関わってきました。 speakerdeck.com 本記事では広告配信システムの刷新を行う中で取り組んだ負荷試験環境を構築する際に考えたことと「継続的にパフォーマンス改善を行うためには
～テストツールを使う際の負荷量の指標～ 6. システムがパフォーマンスを維持するためのメモリ管理について に戻る はじめに 性能テスト、負荷テストを行う上では、達成すべき目標値の定義が必要となります。しかし、性能テストでは様々な指標が存在しており、どの指標をもって目標とし、結果を判定すべきか判断が難しい場合があるでしょう。 実際に、Webシステムの性能評価を行うための指標には以下があります： * 同時接続ユーザー数(Number of Virtual Users) * 時間あたりのユーザーシナリオ実行本数(Transactions per hour) * 時間あたりのページ処理数(Received pages per hour) * 時間あたりのヒット数（Hits per hour） * サーバー平均応答時間(Average Server times, etc.) * サーバー側のCPU
JMeterの簡易的なリファレンス JMeterダウンロード jmeter.apache.orgのDownload Releaseよりバイナリをダウンロード。 必要な環境 JVM 1.5以上がインストールされていること。 JMeterインストール ダウンロードしたバイナリファイルを適当なところに解凍する。 起動方法 Windowsの場合binディレクトリにあるjmeter.batを起動する。 テストの作り方 テスト計画にスレッドグループを追加して、その下にHTTPリクエストなどのサンプラーを追加する。 必要に応じて、ロジックコントローラーや設定エレメントを配置する。 テスト結果の見方 リスナーにより結果をいろいろな形式でみられる。個別の結果を詳しく見る場合は「結果をツリーで表示」を使う。 Debug SamplerやDebug PostProcessorでJMeter変数やプロパティなどの
ども、大瀧です。 ここのところ新機能を追いかける記事ばかりだったので、今回は少し毛色の異なるノウハウ系を書いてみます。 負荷テストの前置き(読み飛ばし可) 「Webサイトがテレビ番組で紹介されることになった！大幅なアクセス増がやってくる！」という場合に、ロードバランササービスのElastic Load Balancing(ELB)やCDNのCloudFrontなどスケールするサービスを組み合わせ乗り切るというのは、クラウドらしい柔軟性の高さを活かせる典型な例かと思います。実際、弊社の事例でも多くのお客様に提供し、ご好評をいただいています。 これらのサービスを構成するにあたり、実際のアクセス増に耐えられるか試すため負荷テストを実施することも多いと思いますが、大規模なケースになってくると難しいのが負荷テストを実施するマシンの確保です。これについてもAmazon EC2であれば、Auto Sca
更新履歴 2014/2/17 コメント頂いた内容を反映、誤字を修正 #なぜELBの負荷テストはJMeterクライアント（GUI）１台からではだめか。 当初、ELB配下に、AZ-Aに2台、AZ-Cに2台の合計4インスタンスがある構成で、自分の開発マシンでJMeter(GUI)を動かして負荷テストをしていたのですが、なぜか、AZ-Aの2台にしか負荷が入っていない。 ググっていたら、AWS Japanの公式スライドを発見 http://www.slideshare.net/AmazonWebServicesJapan/20130612-aws-meisterregenerateelbpublic ↑のp49に、 「都度DNS解決を行うツールが望ましい」 とあります。 なるほど確かに、JMeterはDNSキャッシュしてしまっているようです。↓ https://twitter.com/just_do
8. 負荷テストアプローチ別の目標設定と指標の考え方 7. 負荷テストの評価基準には何 を使えばよいのか? に戻る はじめに 一般的に負 荷テストには、目的に応じて以下の4種類のアプローチがあると言われています。 * 性能テスト - スループット * 性能テスト - 応答時間 * 限界テスト * 耐久テスト 負荷試験はシステムに対する客観的評価手法の 一つですが、何をもって判定基準や達成目標にするかという明確な指標を伴わずに、漫然と一定量の負荷をかけて問題が起きなければそ のまま完了とするスタンスには問題があります。 実行時に明確な目標と指標が無い場合には、採取したデータも活用の出来ない 意味の無い客観データになりやすいですし、また、テスト時に可能である潜在的な性能問題の発見／改善のせっかくの機会を見逃すこと になります。 本編では、これらアプローチ毎の目的設定と指標の考え方について整理し
Apache JMeterのMaster/Slave構成 シナリオを用いた負荷試験といえばJMeterということで、使ったことがある方も多いかと思います。しかし、ほとんどの方は自分のPCを使ってやっている程度ではないでしょうか。最近は、スマホ連動のシステムが多くなってきていますので、1台のPCから負荷を掛けたとしても大した負荷試験になりません。そこで、今回はJMeterをMaster/Slaveのクラスター構成にしてドカーンと同時アクセスを行いたいと思います。 クラスメソッドの負荷試験の歴史 創業時から業務系のシステム開発が多かったことから、レスポンスは3秒以内でOKとか、ピーク時の同時ユーザは100名といった、緩い条件をクリアすれば良かったことが懐かしく思います。今は、ユーザ数・データ量・トランザクション数・トラフィック等が爆発的に増える可能性のあるプロジェクトも多く、負荷試験は必須項目
はじめに 負荷試験ってとっても重要ですが、リリーススケジュール優先でどうしても後回しにされたり、省略される事がありませんでしょうか。 特に近年はクラウドでの動作が前提となっているため、リリース後のスケールアップやスケールアウトが容易であるというということも、事前の負荷試験が軽視されてしまう要因となっているかもしれません。 しかしながら、ある案件で負荷試験を行ってやっぱり重要だなということがわかったので自戒を込めて負荷試験実施からパフォーマンス・チューニングの流れを記載します。 各ツールの詳細な紹介などは自分が参考にしたリンクを随時追記したいと思います。 ※以下、数字は例であり、適当に丸めてあります。 負荷試験を軽視することにより発生しうるケース 簡単に思いつくこと サービスの継続に必要なサーバリソースが予算またはサービスの収入を上回った。（ワーストケース） サービスの継続に必要なサーバリソ
いまやビジネスにとってWebサイトは重要なツールの1つであることはいうまでもない。しかし、そのWebサイトが不安定な状態で、顧客が不快な思いをしたり、使えない状況になっていたりすれば、かえってビジネスにはマイナスだ。今回は、Webサイトを正しく構築・運用する上で、公開前に実施してほしいチェックの1つである“負荷テスト”について焦点を当ててみよう。 Webがアプリケーション開発の基盤として利用されるようになって以来、われわれは社内システムあるいはインターネット上のサービスとしてそれらを利用している。 しかし、サーバやネットワーク機器のパフォーマンスが年々向上しているにもかかわらず、エンドユーザーが感じるパフォーマンスが、さほど向上していないように感じている人は多いのではないだろうか。それどころかパフォーマンスの問題から、エラーメッセージが出ていないにもかかわらず空白ページが現れたり、コンテン
サーバのボトルネックを見極めるには、適切な性能評価が必要。ApacheBenchとJMeterによる、効果的な性能評価のポイントを紹介する。（編集部） Apacheはそのままでも十分なパフォーマンスを発揮しますが、設定値や構成の見直しを行うことで、さらに高い性能を得ることができます。しかし、適切な値を設定しなければ、サーバの潜在能力や許容量をオーバーし、かえってパフォーマンス低下を招く可能性もあります。経験やノウハウの蓄積が少ない状態では、チェック＆トライの繰り返しが必要です。 今回は、チェックのための道具であるベンチマークソフトの使い方とその結果の見方を紹介します。 Webサーバの性能評価とは 性能評価の基礎 性能評価の方法は、 ホワイトボックステスト サーバやネットワーク構成など、評価対象となるWebシステムの構造を理解したうえで、ボトルネックの当たりを付けて試験を行う ブラックボック
Webアプリケーションやクライアントサーバ型のシステム開発の中で性能要件を満たすために負荷試験やロード試験といわれる工程がある。 重要な工程として考えているが、スケジュールの厳しいプロジェクトなどでは後回しにされることがあった。 特に、開発が遅れている場合、要件を満たすための開発が重視されることは理解しているが、負荷試験を実施することは同じくらい大切な工程である。試験で起こることは当然、本番環境でも起こり、あとで痛い目をみないためにも必須の工程である。 負荷試験を設計する上での考え方をまとめてみたいと思う。 以下のサイトが参考になる。 理論的・計画的なWebアプリケーションのテストの実現：第4回 テストを設計するには（その2） (1/2) – ITmedia エンタープライズ 負荷試験とは 構築するシステムがどの程度の負荷に耐えられるかを測定し、システムの信頼性と耐用範囲を明確にする。ウェ
負荷試験対策ミーティング ここでは、チームメンバーを集めて、システム要件の再確認と、バックエンドのアーキテクチャを再確認をまず行います。すなわち、「求められているもの=要件」と、「提供できるもの=アーキテクチャ」の確認です。ここの認識が揃っていないと、的はずれな負荷試験を実施してしまうことになりかねません。立場や役割にかかわらず、サービス全体として考えるべきです。 負荷試験の目的 負荷試験を行うことによって、何を示したいのか決めます。今回は、以下の目的を定めます。 サービスリリース後、想定されるピーク時のリクエストを受けた場合でも、問題なく稼働を続けられることを確認する システムのスループット限界値を確認する 負荷試験の観点 たいていのWebシステムの場合、昼夜を問わず稼働し続けるものとなるでしょう。今回例にとったシステムも24時間365日、リクエストを受け付けるものとします。この場合、観
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
