ソフトウェアエンジニアリングのログブックを開いて、書き始めます。「研究開発チームのログ。 私たちのアプリケーションでこのような失敗を予見することは率直に言ってできませんでした。私にはわかりません。私たちはそれをすべて持っていました。上出来でした ! テストはグリーンで、指標は良好で、ユーザは満足していました、にもかかわらず、トラフィックが大量に到着したとき失敗しました」

深呼吸をするために一息つき、続けます。「私たちは準備ができていると思いました。人気のあるサイトを運営するコツがあると思いました。どうしましたか ? 程遠い。TechCrunchのリンクはそれほど多くのトラフィックをもたらさないと当初は思っていました。また、テレビCMが放送された後の負荷の急増にも対応できると考えていました。アプリケーションが起動直後に応答を停止したとき、このすべてのテストのポイントは何でしたか。また、投入したサーバーの数に関係なく、これを修正することはできず、可能な限り状況を救おうとしました」

長い休止の後、「もう遅いです、時間が経ちます。伝えたいことはたくさん残っています、私が知りたいことはたくさんあり、私が決して作りたくなかった多くの間違い」 止められない、「それを機能させるために私たちにできることがあれば…」

そして、明晰さがあなたに反撃します。あなたは疑問に思います: そもそもなぜ負荷テストを行うのだろう ? 長い開発期間の後にパフォーマンスを検証するためですか、それともアプリケーションから有用なフィードバックを取得してスケーリング機能とパフォーマンスを向上させるためですか ? どちらの場合も検証が行われますが、後者の場合、フィードバックの取得がプロセスの中心になります。

なるほど、これは実際には負荷テスト自体のことではありません。目標は、アプリケーションが稼働したときにクラッシュしないようにすることに重点を置いています。負荷テストの「伽藍」を作成する必要はなく、全体的なパフォーマンスを向上させるための時間はほとんどありません。多くの場合、改善に取り組むことは、すべてではないにしても、ほとんどの時間を費やしたい場所です。負荷テストは、目的を達成するための手段にすぎず、他には何もありません。

締め切りが明日であるために恐れていて、迅速な勝利を探しているなら、ようこそ、これがあなたのための記事です。

可能な限り単純なシミュレーションを書く

この記事では、Gatlingを使用するので、少し精密にScalaコードを記述します。コードは怖く見えるかもしれませんが、そうではないと請け負います。実際、Scalaは今のところ脇に置いておくことができ、Gatlingを独自の言語と考えることができます:

import io.gatling.core.Predef._
import io.gatling.http.Predef._

class SimplestPossibleSimulation extends Simulation {

  val baseHttpProtocol =
    http.baseUrl("https://computer-database.gatling.io")

  val scn = scenario("simplest")
    .exec(
      http("Home")
        .get("/")
    )

  setUp(
    scn.inject(atOnceUsers(1))
  ).protocols(baseHttpProtocol)
}

これを小さな部分に分解してみましょう。Gatlingはそれ自体がJava仮想マシン上で実行されるScalaを使用して構築されているため、予想通り、いくつかの類似点があります。一番目は、コードが常にパッケージのインポートで始まることです:

import io.gatling.core.Predef._
import io.gatling.http.Predef._

#devops #デベロップメント #設計/アーキテクチャ #アーティクル