第8回 性能テスト：ソフトウェアテスト基本テクニック｜gihyo.jp … 技術評論社
性能とは 今回は「性能テスト」について紹介していきますが、その前に「性能とは何なのか」ということを考えてみたいと思います。性能とは何なのか？一言で言うと「システムが処理結果を返す力」です。 たとえば、インターネット上のショッピングサイトで商品を買ったことがある方は多いと思いますが、その時のことを思い浮かべてください。あなたは、とあるショッピングサイトにアクセスし、気に入った商品を選んでカートに追加し、商品購入の画面へ進み、商品を送ってもらう住所や決済のためのクレジット番号を打ち込み、やっとの思いで「商品購入」のボタンを押しました。しかし、なぜか何分たっても結果が返ってきません。不安になったあなたは一度ブラウザを閉じ、再度購入をしてみようとしたところで、やっと結果が返ってきました。それまでの時間、約3分。このような場合、あなたならどう感じますか？ もちろんイライラしますよね？ そう、この「シ
1ヶ月で負荷テストの基礎から学んで実際にやってみた知見 | BLOG - DeNA Engineering
はじめに こんにちは。DeSCヘルスケアシステム部でインターンをしている中島です。本記事では開発に関わった2つのサービス「ハレトケ」「カラダモ」の負荷テストで得た知見について紹介したいと思います。 負荷テストをこれからやる方や、システムのパフォーマンスチューニングに興味のある方などの参考になると嬉しいです。 負荷テストの目的 まず、負荷テストをどのような目的でやるのかについて抑えておきます。一般的にクラウド環境での負荷テストの目的は以下の5つが挙げられます。（出典：Amazon Web Services負荷試験入門 ――クラウドの性能の引き出し方がわかる Software Design plusシリーズ） 各種ユースケースの応答性能を推測する 高負荷時の性能改善を行う 目的の性能を提供することができるハードウェアをあらかじめ選定する システムがスケール性を持つことを確認する システムのスケ
負荷試験を恐れないための基本あれこれ
私は負荷試験が怖いです。 それなりに慣れたつもりですが必要となる知識領域は広く、 トライ&エラーの繰り返しでなかなかに大変な作業となります。 そんな自分や、ビギナーが恐れず挑めるように基本部分をまとめてみます。 負荷試験の目的 負荷試験とは、機器やソフトウェア、システムのテストの一種です。 行う目的としては下記があげられます。 性能の計測 負荷を高めたときの状態や性能などを計測し、どのくらいの負荷まで正しく動作するかを検証します。 高負荷時の性能改善 処理が詰まりパフォーマンスが出ない場合のボトルネックとなる部分を特定します。 特定後、ボトルネック解消を行いパフォーマンス向上につなげます。 ハードウェアスペックの選定 試験結果から実際にサービスで運用する本番構成のスペックを確定させます。 スケーラビリティ（拡張性）の確認 スケールアウト等を行った際に、期待どおりに性能が拡張されるかを検証し
Web Vitals | Articles | web.dev
Web Vitals Stay organized with collections Save and categorize content based on your preferences. Web Vitals is a Google initiative to provide unified guidance for web page quality signals that are essential to delivering a great user experience on the web. It aims to simplify the wide variety of available performance-measuring tools, and help site owners focus on the metrics that matter most, the
スループットとは何か ～ 改善に役立つ性能試験を行うための前提知識
「スループット」という言葉を、どなたも一度は聞いたことがあると思います。主にアプリケーションなどの性能（パフォーマンス）の文脈で使われますが、そのためにはスループットを正しく把握できなければなりません。スループットを正しく把握するためには、そもそもスループットについての正しい知識や理解が必要です。本稿では、パフォーマンスの改善に効く性能試験を行えるよう、スループットとは何かを解説します。 負荷試験とは何か パフォーマンス全般の担保を主な仕事とする我ら「まかせいのう[1]」チームにとって、性能試験は頻繁に実施するタスクの1つです。性能試験と一口にいっても色々と種類がありますが、システムの性能を担保するうえで最も重要になるのがEnd-to-Endの負荷試験です。 End-to-Endとは「フロントエンドからバックエンドまで、ユーザから実行された処理が通過するシーケンスすべてのコンポーネントを範
データベースを遅くするための８つの方法
はじめに Twitterのタイムラインを見ていたらバッチ系のプログラムで逐次コミットをやめて一括コミットにしたら爆速になったというのを見ました。当たり前でしょ、と思ったけど確かに知らなければ分からないよね、と思って主に初心者向けにRDBを扱うときの注意点をまとめてみました。 プログラミングテクニック的なところからテーブル設計くらいの範疇でDBチューニングとかは入ってないです。 自分の経験的にOracleをベースに書いていますが、他のRDBでも特に変わらないレベルの粒度だと思います。 大量の逐次コミットをする バッチアプリケーションでDBにデータをインサートすると言うのはかなり一般的な処理です。しかしデータ量が少ない時はともかく大量のインサートを逐次コミットで処理するとめちゃくちゃ遅くなります。数倍から十数倍遅くなることもあるので、10分程度のバッチが１時間越えに化けることもザラにあるので原
Webアプリ負荷試験ガイド - withgod's blog
Webアプリ負荷試験ガイド 目次 Webアプリ負荷試験ガイド 目次 前置き 時間がない人向け要約 about me 何故負荷試験を行うのか 負荷試験ツール 負荷掛けるツール 負荷計測 負荷の可視化 負荷試験の流れ 負荷試験スケジュールについて 注目すべきポイント シナリオ作成 アカウント情報は自動生成出来るようにする DB分割を行ってる場合はDB分割を意識したシナリオを用意する。 負荷試験元 http or https サーバ1台 サーバ単体での負荷 アプリの正常性の確認 サーバ複数台 KVS Memcached Redis RDB 問題になりやすいDB キャッシュの話 大前提 注意すべき点 CDNやProxyレベル local cache or remote cache local cache or memory cache(in app cache) references 更新情報 前
負荷テストツールGatlingを触ってみた - 絶品ゆどうふのタレ
負荷ツールとしてGatlingのことを少し前から耳にする機会が増えたので、利用してみることにした。 色々既出だとは思うが、公式のQuickstartに従って試してみたのでメモ。 GUIが必要だったので、今回は手元のMacで実行。 Gatlingとは Java/Scala製の負荷テストツール。 JMaterと似た感じのツールではあるが、 ハイパフォーマンス 見やすいレポートHTML developerフレンドリーなシナリオファイル というのをウリとして謳っている。 たぶん、3項目とも対JMater(重い・レポート見づらい・XMLのシナリオつらい)を意識したメリットだろうなー。 なお、シナリオファイルは。。。 Gatling simulation scripts are written in Scala, but don’t panic! わろた。 というわけで、触ってみる Install J
性能テストの概念的な話 - Qiita
はじめに 一般的なWebシステムを念頭に、性能テスト（performance testing）の概念的なところについて少しまとめてみました。 個別のツールや、チューニングについての記事は多いですが、大枠のフレームについての記事があまりなかったので、書いてみましたが、誤りなど指摘いただけますと幸いです。 最初性能テストの話をまとめようと思っていたのですが、考えてみたら、要件があり、設計があり、テストがありと、一連の流れが必要なのでした。 まずはテストプロセスの定義から。定義についてはこちら1を参照しています。 （テストに関する用語はなんでもそうですが、定義している団体や個人によって、意味合いが異なっています。なので、ここに書いたことはそれを念頭に置いて頂ければと思います。人によって、高負荷テスト、高負荷試験etc...なんでもありですしね） テストプロセスの定義 性能テスト（performa
ハード性能以上の性能は出ないんです
こうした考え方に沿うと、性能要件として、ユーザー数やデータ件数しか記載されていない場合は、条件が不足していることになります。例えば「ユーザー100人が同時にアクセスしても問題なく利用できるシステム」というのは、一見すると性能要件としてもっともらしいのですが、実際にはユーザーの操作の内容や頻度によって、求められるハードウェアはまったく異なってくるのです。 また、性能要件が業務量の見込みの値を前提としている点にも注意が必要です。社内システムのような利用者が限定されているシステムでさえ、、見込みと現実が完全に一致するというのはまれなケースでしょう。業務量が想定どおりにならない可能性に備えておくことこそ、プロアクティブな性能管理といえます。 2）性能要件とIT基盤要件の関係を把握する 性能要件が決まれば、その条件を満たすハードウェアスペックを求めていきます。性能要件と同様、これもまた不確実さを伴う
第1回 性能品質は開発工程全体で作り込もう
性能要件の実現は重要だと認識しながら、「結局、性能は構築し終わるまで分からない」といったスタンスでプロジェクトに臨んでいないでしょうか。最初に性能要件を定義したあとは特に何もせず、カットオーバー直前にわずかな性能テストとチューニングを行うだけというケースを、筆者はよく見かけています。 そのようなスタンスでシステムを開発しても、性能要件をしっかりと実現できる可能性は高くありません。カットオーバー直前にその場しのぎの対策をするか、巨額の追加コストをかけてハードウエア増強に走る、といった状況に追い込まれがちです。 ITシステムの性能品質は本来、ライフサイクル全体を通して作り込むものです（図1）。設計、実装、テストの工程を通じて、システムの性能要件達成に取り組み、検証していく必要があります。 本連載では「システムの性能を確保するために何をすべきか」というテーマで、性能をマネジメントするための考え方
保存版 性能品質の作り方
性能品質のよしあしは、要件定義で抽出された性能要件を満たしているかどうかで判断します。開発フェイズでは、設計、実装、試験を通して性能品質を作り込むプロセスを実施します。確保した品質を前提に、管理とメンテナンスを行うことで、運用フェイズでのSLA（サービス・レベル・アグリーメント） が実現できるのです。 では具体的に何をすればよいのか、前回までの連載の内容を踏まえて整理します。 要件定義 性能要件とは、システムの目的を達成するために必要な条件であり、前提条件と目標値として整理します。前提条件とは、処理対象となるデータ量や取引数、ユーザー数などがこれに当たります。目標値とは、レスポンスタイム、同時接続ユーザー数、単位時間当たりの取引件数などです。どちらの数値もモニタリング可能な項目（モニタリング可能とは、ログに出力されているか、ツール／コマンドで参照できることです）を選ぶのが性能マネージメント
性能問題の失敗事例集
性能設計とは、目標性能と、その目標を実現するための設計です。業務量に応じたサーバサイジング、プロセス構成、業務処理の対象データ件数や処理の多重度などと多岐にわたり、性能マネジメントの中で最も重要な要素の1つといえます。（本文より） 失敗は成功の母といわれるように、失敗からはたくさんの教訓を得ることができる。連載第2回は、性能マネジメントで押さえるべきポイントを、失敗事例から学んでみたいと思う。 思い出すと心拍数が上がる性能問題の数々 さて今回は、私の身近で発生した性能問題の事例を振り返り、「攻めの性能マネジメント」として、性能問題予防のために実施すべき具体的な作業と考え方を整理したいと思います。 事例1：カットオーバーに間に合わない！ ある通信系システムでは、アプリケーションの品質が安定しなかったこともあり、開発工程の最後に性能評価を実施したところ、性能問題だけでなく、機能試験では抽出でき
第2回 「応答一律3秒」という性能要件はやめよう
今回は、性能要件を具体化するポイントを紹介します。皆さんは、性能要件に何を定めればよいと思いますか。 システムの性能要件で、「Webアプリケーションの画面レスポンス時間は3秒以内であること」「バッチアプリケーションは毎日午前0～午前5時の間に終了すること」としか定義していないプロジェクトを見かけます。この場合、以下のような問題が潜んでいます。 （1）全機能の処理時間を同じレスポンス時間に収めなければならない 全機能に対して同じレスポンス時間を目標とするのは現実的ではありません。なぜなら、機能によって求められるレスポンス時間と処理の複雑度は異なるからです。 例えばコールセンターのシステムで、「（a）電話オペレーターが操作する画面」と「（b）管理者がマスターデータをメンテナンスする画面」があるとします。レスポンスの悪化が直ちにビジネス機会の損失につながる（a）の方が、求められるレスポンス時間は
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
スループットとは何か ～ 改善に役立つ性能試験を行うための前提知識