性能
関連:パフォーマンス
レイテンシ
スループット
IOPS
性能#63cd520bb3641f0000c95eb1
性能#65163f6ab3641f0000a2acf8
ネットワーク性能(要因)
CPU
メモリ
参考
性能テストについて纏めてみた
1ヶ月で負荷テストの基礎から学んで実際にやってみた知見 | BLOG - DeNA Engineering
Amazon CloudWatch メトリクスを使用して Amazon RDS についてより適切な意思決定を行う | Amazon Web Services ブログ
Q&A
Q.icon よく言う「4KB以下を大量に書き込むならIOPSを意識、逆に大きいサイズを書き込むならスループットを意識」て言うのがいまいちわからない
a.icon
IOPS, スループットについてのインプットが前提
ストレージには基本的に、限界スループット、限界IOPSってのが設定されてる
その状態で、処理の要求数が増えるとIOPSが増えやすくなり、ストレージの限界値に到達しやすい。
逆に処理の要求サイズが大きくなるとスループットが増えやすくなり、ストレージの限界値に到達しやすい。
後は具体的な数値でイメージしよう(AWS EBSを例に)
EBSではSSDの場合、IOサイズの最大が256KBとなっていた。
例えば、このストレージのIOPS限界が3000だとしよう。そしてスループット限界が126MB/sだとしよう。
この時、多重度1でめちゃくちゃ大きなサイズの要求を行うユースケースがあったとする。
その場合、IOPSの観点だけで考えると、可能な要求サイズは 256KB x 3000 = 768MB/sとなる。
ここで、よく前提を思い出してほしい。スループット限界は126MB/sなので、IOPS的には大きいサイズを乗り越えれたとしても、スループットは乗り越えれない。
このことから「大きいサイズを読み書きするときは、スループットの方がボトルネックになりやすい」と言える。
「AWSだけの話じゃないの?他のストレージだとサイズ大きくしたら、先にIOPSの方がガタが来るかも...」
どこでも見る言い回し(= 小さいサイズがいっぱいならIOPS、大きいサイズならスループット)なので、基本的にはこの慣習がどこのストレージでも当てはまりやすいんだと思う。
ただ、確かにこの疑問は間違ってはいないはず。ストレージによっては、要求サイズを大きくしたら先にIOPSの方がガタが来る可能性もあるかも。
なので重要なのは、ストレージのIOPSかスループットのどちらがボトルネックになってるのかを実際に確認することが大事。
AWS EBSの例で、1回の要求サイズが32KBのパターンで、1秒間の要求数を限界IOPSの3000にしたとする...
スループットは...32KB x 3000 = 96MB
スループットの限界はまだ来てない。耐えてる。
ただ...以下の要求サイズが50KBとかだと、150MB/sになって、スループットの限界を迎える。
と言った感じで、実際に動かしてスループットかIOPSのどちらがボトルネックになるのかを見極めると良い
殴り書き(思考)
ポイント
性能は簡単に言ってしまうと「システムの様々な箇所におけるリソース能力」と「システムに対して要求される処理量」の関係で変わると言うことを理解する。
スループット、レイテンシというのは、性能の結果であり、要件通りの性能が出てるかどうかの判断基準でしかないことを理解する。
スループット、レイテンシが要件よりも下回って初めて、性能解消に動き始めるようになることも理解する。
性能を解消する際は「1. 現状の要求処理量」「2. 要求処理量をスムーズに捌けない原因となってるシステム内のボトルネック」を調べ、スループット、レイテンシを上げるための施策を考える。
ボトルネックの箇所によって原因解決策は変わるし、その中でも様々な方法が出てくることを知っておく。
ex:そもそもの要求処理量を下げる、冗長化して負荷分散する、ネットワーク帯域を上げる、I/O待ちを解消する、etc
性能はややこしい....
一旦、クライアントに処理結果を返す時間をできる限り早くしたいなら「レイテンシ」に着目せよ
そして「レイテンシ」を短くするには、システム全体および細かい箇所の「スループット」の改善を試みよ
スループットを上げるには、CPUやメモリ、ネットワークなどの「リソース能力」に着目せよ
CPUが100%とかになってたら、出せるスループットに限界が出てることを意味してる
こういうのをいわゆるボトルネックと言う。
= 処理性能の限界になってる部分のこと。
スループットとレイテンシのトレードオフについて
正直何言ってるのかよくわからんかったが以下のように解釈すればわからない話でもないなと...
処理Aがあったとして、この処理が要求する処理量(スループット?)があるとする。
この要求処理量が増えれば増えるほど、レイテンシは上がる。
単純に考えて「10,000件のデータを処理してくれ」「100,000件のデータを処理してくれ」の間には、処理結果を受け取れる時間に差があることがわかる。
つまり、スループットとレイテンシのトレードオフとは以下
要求する処理量が増えれば増えるほど、レイテンシは長くなる
逆に、要求処理量が小さいならレイテンシは短くなる可能性が高い
ここで言うスループットとは「クライアントが要求する処理量」のことであり、サーバー側などが出せる最大スループットとはまた意味が違うと言うことを知る。
クライアント側から見たスループットの意味
1.icon 要求スループット(= 1処理・リクエストが要求する処理量)
サーバー側から見たスループットの意味
2.icon 潜在的最大スループット(= そのサーバーが持つリソースを持ってして最大限に出せる処理量)
3.icon 現状スループット(= そのサーバーがリアルタイムで出してる処理量。時間で値は変わる。)
さらに殴り書き思考
最初に性能について思考した時から8ヶ月経って、より解像度が上がったと思うので、再度性能について記録しておこうonigiri.w2.icon
まず性能を考える際は、その処理に関わる全てのメンバーを洗い出すことから始める。
処理に関わるっていうのは、例えば以下のような構造がある場合
1. クライアントがリクエストを出す
2. サーバーがリクエストを受け取って処理を始める
3. サーバーが別のメンバーに何かを依頼する
4. サーバーがそのメンバーから結果を受け取りつつ、クライアントに結果を返す
少し単純な例ではあるが、「何か処理をする!」という開始点から終了点までで関わった全てのメンバーを洗い出すこと。
メンバーってのが曖昧だよなonigiri.w2.icon
性能の上下に関わる媒体全てが対象。
ex)ネットワーク、ストレージ、コンピューティングリソース、ローカルPC、モバイル、などなど
そういった通信をやり取りしたり、計算したりすることが可能な奴ら全て。
性能って言ってもさらに何を測るのかってのもある。
クライアントからの1リクエストが完了する時間なのか
あるデータ処理の際、1秒に処理できるデータ量のことなのか
主にこの2つだな。