こんにちは Set Retail 10システムのパフォーマンスを理解する道をどのように進めたか、つまりパフォーマンスを測定する方法を学び、その変化をどのように追跡したかをお伝えします。
テストのためにパフォーマンスベンチを構築し、数日間にわたってストレステストを実行しました。 テストベンチを開発する段階で、激しい紛争のシールドについて多くのコピーを壊しました。 しかし、何とどのように、そしてどのような順序で-最も重要な質問に対する答えを見つけることができました。 私たちの経験があなたに役立つことを嬉しく思います。
Set 10サーバーに関するいくつかの言葉これは、約100個のモジュールに分割された500個のBeanを持つエンタープライズJavaアプリケーションです。 各ビンは、他のビンとほぼ接続されています。 この小さな軍隊（または大隊）は20〜30個のデータストリームを処理します。 論理的には、それらは互いに依存していませんが、すべてが同じマシン上で回転しているため、データの流れが流れ始めると、これは他のプロセスに影響します。 このシステムを、豆が「調理」され、そこに投入されるすべてを「消化」できるボイラーと比較します。
最近まで、Set 10サーバーのパフォーマンスの問題は襲撃によって解決されていました。 私たちの観点から、最適に機能しなかった場所を見ました。 そのような場所については、これらの場所を読み込み、何らかの形で「開通性」を示すワンタイムスクリプトが作成されました。 さらに、このような「問題領域」を最適化するための作業が行われ、「負荷と測定」スクリプトが再度実行されました。 結果によると、違いが見え、結論が出され、この場所でどれだけ速度が向上したかがわかりました。 その後、彼らは当局に報告しましたが、誰もが幸せでしたが、私たちは1つの質問に答えることができませんでした（そして私たちはしばしば尋ねられました）：「OK、これを最適化しましたか？ 彼女はどれくらい速く仕事をしましたか？」
これはさらに続きますが、生産性の問題に対する体系的なアプローチを開発する必要がありました。 この推進力は、複雑なシステムがスピンする鉄のシステム要件を提示する必要があることです。 そして、ここでの困難は、多くのモジュールがあり、多くのデータストリームがあるという事実にあります。 システムの各ユーザーは、一部のモジュールを使用でき、他のモジュールは使用できません。 たとえば、あるクライアントは外部のロイヤルティシステムを使用できますが、これはサーバーのモジュールのほとんどをロードせず、別のクライアントは何百万ものクライアントカードを持ち、ボーナス、クーポン、ギフトなどを積極的に使用します。
1人のクライアントは300のキャッシュデスクから30分で1つの小切手を生成でき、別のクライアントは20のキャッシュデスクのそれぞれで1分あたりのチェック速度でアクティブな取引を実行できます。 このような「複雑なシステム」の同じバージョンでも、クライアントごとに要件が異なる場合があります。 これが、「襲撃」のシステムがこの問題の解決に役立たないという理解が生まれた場所です。 システム全体に要件を設定することはできません。 クライアントがどの構成を持っているかを知る必要があり、これが最初に発見された依存関係です。
この質問に答えるには、いくつかの機器m1、m2、...を用意する必要があります。 構成k1、k2の特定のセット...および各構成kiの機器mjを見つけます。この構成は、クライアントのタスク、つまり販売サービスに対応します。 （オプションの数を何らかの形で減らすために）基本構成として採用した3〜4の構成を個別に識別し、要件を探すことをすぐに言わなければなりません。 だから、主な質問は、特定のサーバーが特定のマシンでどれだけうまく機能するかです。 つまり、Mj機器のKi構成を取得し、システムが正常に機能するかどうかを判断する方法は何ですか？
論理的には、これは負荷の下で実行されているサーバーの数を一致させる関数です。
F（x）-> y
このような機能をコード/スクリプト/スタンドの形式でプログラムすると、私たちに提起されたすべての質問に答えるのに役立つ強力なツールが得られます。 しかし、まず最初に。
F（x）：それはどんな種類の関数で、どの変数から考えられますか？
この関数は、複雑なシステムがどれだけうまく機能するかを考慮します。 実装に入らずに、少なくともアイロン（システムが遅いマシンよりも高速に動作するマシン）、複雑なシステムの構成（上記で述べたように、誰かがモジュールのみを使用する、他の人）、コードのバージョン（システムの新しいバージョンのリリースに伴い、パフォーマンスが向上する場合があります） ここでは、あなたに固有の何かを思いつくことができますが、私たちの会社では、これらのパラメーターがパフォーマンスの依存関係をよく反映していることに同意しました。 3つの変数からの合計関数が判明しました。
-> y：意味は何ですか？
サーバーが正常に動作しているかどうかの数値インジケーター。 数が多い場合、サーバーは正常に機能します。 数が少ない場合、サーバーは十分に機能していません。 この数値は、抽象的なもの（パフォーマンスポイント）または非常に具体的なもの（特定の単位の速度）のいずれかです。 これが1つの数字であることが重要であり、その理由が明らかになります。 当社では、この割合を今回の実行で達成されたビジネス要件の割合とすることに同意しました。 つまり、結果F（x）= 84％を取得した場合、これはシステムがビジネス要件を84％満たすことを意味します。
合計、関数の説明は次のようになりました：
F（ハードウェア、構成、バージョン）->ビジネス要件の％
この機能をプログラムで実装できる場合は、パフォーマンステストスタンドを取得します。これにより、構成に適したハードウェアを生成でき、鉄に基づいて、システムのどの構成が信頼できるかがわかります。 とりわけ、このようなスタンドでは、（ハードウェアと構成を修正することで）バージョンごとにパフォーマンスを測定することができます。ハードウェアとバージョンを修正する場合、他のパラメーターよりもパフォーマンスに影響するパラメーターを選択できます。
構成
パフォーマンス機能の3つのパラメーターのうち、構成のみが問題を提起します。 実際、異なる機器で同じテストを実行すると、パフォーマンス関数の値が異なりますが、これは理解可能であり、特別な問題を引き起こすことはありません。 バージョンにも問題はありません-異なるバージョンでテストを実行すると、自由なディメンションもあり、必要に応じて変更できます。 しかし、構成には大きな疑問がありました。 たとえば、構成に含める必要があるパラメーターは何ですか？ それらを組み合わせる方法は？ プログラマーまたはビジネス-誰がそれらを策定する必要がありますか？ 特定のケースで測定するものは何ですか？
多くの議論の後、次の結論に達しました。
1.開発者は、パフォーマンスに影響するシステム内の要因のリストを作成します（この点については開発者の方が知識が豊富です）。 そのような各要素は、すべての開発者とビジネスに理解可能でなければならず、それをロードして測定できる必要があります。 要因のリストは、開発者に従ってパフォーマンスへの影響の順にソートする必要があります（実際のテストでは、この仮定を確認または反論できます）。
2.次に、ビジネスはリストの各要素に要件を設定します。 要件は、システムの他の部分、鉄、または他の要因に依存してはなりません。 また、これらの要件を定量化に使用しました。要件が満たされている-100％、要件が半分満たされている-50％など。
3.システムは1台のマシンで実行されるため、一度に1台ずつチェックすることは不可能であるため（すべて順番にすばやく動作しますが、実際のお客様と一緒に-速度が低下します）、すべてを一度にロードする必要があります。
例：
小売業者の販売自動化システムにおけるこのような要因の例：商品の積み込み速度、カード、現金デスクからの小切手の配達速度、報告速度、...
ビジネス要件の例：商品の速度-すべての現金窓口まで100品/秒、すべての現金窓口まで100枚/秒のカード速度、小切手配達時間は5分を超えてはなりません。
これらの要素の構成の例（ミドルストア）：ロードされた商品-300,000、カード10,000,000、キャッシュレジスタ-20、チェックはキャッシュレジスタから送信されます-1チェック/キャッシュレジスタ/分。
実装
パフォーマンススタンドを実装するために、このようなスタンドの基礎となる既製のソリューションをいくつか検討しました。
要件は非常に簡単でした：
1. sh / batスクリプトを実行して、ロードする前にリモートマシンにシステムをインストールおよび構成する機能
2. Javaコードを実行してリモートマシンにシステムをロードする機能
3.テスト中にマシンの基本的なメトリック（メモリ、ディスク、プロセッサ、ネットワーク）と内部メトリック（HTTP経由の可用性、データベース内の内部キュー）の両方を削除する機能
4. 1ページに受信したすべてのテストデータをグラフ形式で表示する機能。 追加のテストデータ（低速クエリのログ、メモリ分析結果など）が存在する場合があります。
私たちが試したもの：
1. JMeter-負荷テストシステム。 非常に具体的なツール。 もともとはWEBアプリケーションをロードするために開発されたもので、これは感じられます。 任意のパフォーマンステストを実装して、ロードフローがテストの特定の場所に作成され、PREテストとPOSTテストの段階があるようにすることは非常に困難です。 テスト結果の視覚化には多くの問題があります（一部のグラフは組み込みであり、グラフを生成できますが、それでもJMeterの外部に共通ページを生成することになっています）。 一般的に、さまざまなJMeterノードとそのシーケンスと制限を理解するよりも、テストアルゴリズムをJavaで記述する方が簡単であることが判明しました。
2. Zabbix-監視システム。 スクリプトを実行し、メトリックを監視できます。 テストロジックをスクリプトに縫い付けること（実際にはこれを行いたくありませんでした）またはJavaでレンダリングする可能性を検討しました。 zabbix'aの大きなプラス-システムの主要なパラメータを監視する方法を既に知っているため、監視用の独自のパラメータを簡単に追加できます。 さらに、視覚的なチャートがあります。 しかし、さらに簡単なソリューションが見つかりました。
3.概要-監視システム。 リモートマシンの基本的なパラメータを監視できます。 インストールが簡単で、サーバーとして実行され、HTTP / Json APIを備えています。 すべてが非常にシンプルで便利です。
その結果、Javaでテストロジックを実装し、一目で監視を行い、小さなWebサービスでテストを実行して結果（html、js）を表示できます。グラフにはchartJSを使用しました。
次のようになります。 
