goader-ファイルの書き込み/読み取りのバイアスを使用したコンソールベンチマーク

goaderは、シンプルな構成とテスト用のさまざまなバックエンドのサポートを備えたコンソールベンチマークです。 名前はgo and loaderに由来し、英語では「槍、棒でカスタマイズする」という独自の意味もあります。

現時点では、テストすることができます（引数-requests-engine ）：

• http（GETリクエストまたはGET + PUT）
• ディスク
• s3（ACCESS / SECRETキーによる承認では、エンドポイントが必要ですが、これによりプライベートs3を確認できます。署名ver4は現在サポートされていませんが、私は計画しています）
• nullおよびスリープを使用して、ベンチマーク自体をテストします

バイアスは、ページではなくファイルの書き込みと読み取りに基づいています

使用例

goader -rps=300 -wps=150 -min-body-size=1 -max-body-size=128k --max-requests=1000 -requests-engine=disk -url=tmp/NN/RRRRR
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ポイントは各リクエストに応じてリアルタイムで表示されます。これにより、数字があまり役に立たない場合に、問題を視覚的に特定することができました。 それらの場所にエラーがある場合はEになります

ストレステストには多くのユーティリティがありますが、私は個人的にそれらに対して多くの苦情があります。

問題番号1、何をテストしていますか？

「並列スレッドの数」に重点を置き、最大負荷、最大スレッド数を検索します。 または、固定数のスレッド。 これは確かに素晴らしいことですが、個人的には、実際には、システムのコンポーネントを交換するときに、この質問はめったに発生しません。 コンポーネントを交換する場合、さらに2つの質問があり、それらは異なります。

a）所定の負荷での応答。 たとえば、50 PUT / s、300 GET / sのように。 古いシステムと新しいシステムの応答時間を確認してください。 コンポーネントを交換しても、ユーザー数は増加しません。通常、目標はシステムの応答性を改善することです。

 goader -rps=300 -wps=50 -min-body-size=1 -max-body-size=128k -requests-engine=upload -url=http://localhost/files/user_NNNNN/file_RRRR
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

b）私たちはまだそれ以上のものを与えたい、システムの最大値を知りたい。 繰り返しますが、それは何ですか？ サーバーが処理できるクライアントの数は？ N番目の割合のエラーを受け取る同時クライアントの数は？ 非常に多くの場合、エラーはありませんが、優れた応答時間が得られます。

したがって、私にとっては、システムの最大値を「応答時間が指定値を超えない並列クライアントの数」と定義しました。

 goader -rpw 2 -max-latency 5ms -requests-engine=disk -url=tmp/RRRRRRR -body-size=4k -max-requests=30000
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

負荷はWRITE（PUT / WriteFile）に合わせて調整され、READの数はWRITEに対して相対的に設定されます。つまり、書き込みごとの読み取り、書き込みから読み取りまで、例2では小数になります。

スレッドの数は遅延に適応し、出力では、この負荷で処理できる同時クライアントの数を取得します。 オプションで、-max-channels引数を使用して、デフォルトで32に最大値を制限して増やすことができます。

従来の「同時クライアント数」も存在します。-wt= 5 -rt = 10（書き込み用に5スレッド、読み取り用に10スレッド）。

これらは私が欠けていた2つのモードです。 しかし、チェックしたベンチマークには別の問題番号2がありました。

構成の複雑さ

私自身に設定された追加の要件は、UIと構成ファイルの欠如でした。 これはもちろん、無数の設定があり、可能性が無限にある場合は非常にクールですが、このためには、構成を書き、これらのファイルを一緒にドラッグするために半日、別の強力なマシン、UIが必要です。 もちろん、これでもまだプラスになる場合があります。サーバーのいずれかに接続し、メモリテストシステムを手動で実行できることが重要でした。 または、チームと余裕のある従業員に短いメッセージを送信すると、彼らは自分ですべてを行います。 極端な場合、彼らはgoader --helpをスパイし、再び、すべてを自分で終了します。

これまでのところ、構成ファイルがなくてもかまいません。そのままにしておきたいと思っています。

たとえば、多くの場合、パスのリストは個別のファイルとして提供されます。 代替： -url=http://127.0.0.1/user/NNNN/images/RRRRRRR.jpg





NNNN-乱数に置き換えられます

RRRRRRR-ランダムな文字に置き換えられます

XXXXX-連続して増加する数字に置き換えられます

可視性

数字は数字であり、目で見ると、数字で見るのが困難で、何を探すべきかわからない異常を見ることができます。 各要求はコンソールにドット（緑-読み取り、青-書き込み）、エラーEで表示され、上矢印または下矢印でスレッドの数を変更します。

この機能により、特定の時点でパフォーマンスがどのように低下​​したかを視覚的に確認できるため、システムの問題を見つけることができました。

さらに、最終結果は簡潔かつ有益であることも求めています。 jsonに置き換えることができます-output=json/human





ポイントが干渉する場合があり、無効にすることができます-show-progress=false

多数のリクエストがある場合、またはリモートで実行する場合、目で進捗を確認するのは難しい場合があります。このため、リクエストが出された-timeline-file=timeline.html



て、視覚的な表示（ -timeline-file=timeline.html



）でhtmlファイルを作成する実験的な機能があります。 改善する計画があり、リクエストの有効期間の表示を垂直に変更すると、何時にリクエストが存在したかがより明確になります。 しかし今のところ、これは優先事項ではありません。

単純なHTTPリクエストのサポート

簡単に言うと、PUTが上記のすべてを使用せずに、ページへのGETリクエストのみを意味します。 これは優先事項ではありませんでしたが、使用できます。

1秒あたりのリクエスト：

 goader -rps=300 --max-requests=1000 -url=http://localhost/user/NN/product/RRRR
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

同時クライアント数：

 goader -rt=32 --max-requests=1000 -url=http://localhost/user/NN/product/RRRR
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

指定された最大遅延を持つ同時クライアントの最大数を検索します。

 goader -wt=0 -max-latency=300ms --max-requests=1000 -url=http://localhost/user/NN/product/RRRR
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

より正確な結果を得るには、このモードでより多くのクエリを実行することをお勧めします。

ちなみに、これはgoの最初の経験でした。実際にレイブレビューをチェックしたかったのですが、サポートしていないとは言えません。 はい、欠点がありますが、一般に、高速コンパイル、迅速なエラーチェック、単一のエコシステム、単純な型システム-これらすべてにより、ファッショナブルなように、エコシステムの機能ではなくコードに集中することができます。

そして、出力に不必要な魔法がなければ、すべてのシステムのバイナリが取得されるという事実は一般的に素晴らしいです。

linux / 386 linux / amd64 windows / amd64 darwin / 386 darwin / amd64のみをgithubにアップロードしますが、このリストを拡張する必要がある場合は問題ありません。 golang自体がサポートするフレームワーク。 コード自体に関するコメントも歓迎します。

Githubからダウンロードするか、MITライセンスで自分でビルドできます。 使いやすくするために、$ PATHを入力することをお勧めします。