Help us understand the problem. What is going on with this article?

Webサービスのパフォーマンスに関する考え方まとめ

More than 3 years have passed since last update.

自分の経験をドキュメントに整理する目的で書き出し。

どうやって効率を良くするか、という観点ではなく、今のシステムのパフォーマンスはどの程度か、という事を把握する目的。

流れも関係なくざーっと書いているので随時構成は変更する。
内容も随時更新。
突っ込み歓迎。

Webサービスパフォーマンスとは

ここでは、以下に書くように狭義なものと広義なものを定義する。一般的な定義ではなくオレオレ定義なので注意。

狭義:ユーザーがアクセスしてからレスポンスが返ってくるまでの速度。

Webサイトやアプリが早い・遅いという時の一般的な指標。
そもそもこの段階でパフォーマンスが悪いとユーザー体験が非常に良くないもっさりとしたサイトとなる。

大体の目安として

数十ms以下 : 早い

100ms ~ 500ms : ちょっと遅いかな

500ms ~ 1s : もっさり

1s以上 : ヤバい

という感じ。ただし、モバイルアプリなどで非同期でAPIを叩く様なサービスの場合にはレスポンスが遅くてもユーザー体験が落ちない様に作る事は出来る。

遅くなる要因としてはいくつかあるが代表的な物を挙げる。

無駄な処理を多くしている

一度に必要以上の処理を行っている、キャッシュすれば良い部分でも毎回計算が走っている、などなど、余計な処理によってパフォーマンスが悪くなっている。

データベースを正しく利用出来ていない

大抵の場合、indexがうまく使えていなくクエリが遅い。サービスがグロースしてデータサイズが大きくなって来ると顕在化する場合がある。

ユーザーとサーバー間に物理的な距離がある

物理的にサーバーがアメリカにあって日本からアクセスする様な場合。往復するだけで100msくらいかかる。

ネットワークが遅い

ネットワークの品質の問題。モバイルの3G回線やネットワーク状況の悪い海外、地下など。

広義:サーバーのリソース使用状況も含めたパフォーマンス。少ないリソースで多くのリクエストをさばく事が目的。

処理が早くてもサーバーのリソースを必要以上に使っている場合にはパフォーマンスのチューニングが必要。

リソース

サーバーのリソースは代表的には以下の4つ

CPU

計算する人。脳みそ。
無駄にループが走っていて計算回数が多かったりするとここがネックになる。
基本的には、CPUが最終的なネックになって来る。
ハード的にはコア数がどんどん増えているのでマルチコアを考慮した使い方をしていく事が大事。

Memory

プログラムをロードしておくところ。机の広さに例えられる。
一つのプロセスを立ち上げるのに大量にメモリを使ったりするとコスト効率が悪くなる。
また、出来るだけプロセス間でメモリを共有出来るようにすると多くのプロセスが立ち上げられるようになる。
CPUにネックが無い場合、プロセス数の上限は大抵メモリで決まり、どのくらいリクエストがさばけるのかはプロセス数で決まるのでそこの見積もりは重要。

Disk IO

Diskの読み取り速度。
メモリに乗らない情報はDiskに書き出したり読み出したりするがそこの速度差は比較にならないほどDiskに書く方が遅いため、大量のIOが発生する様な処理を行うとそこで処理が詰まったりする。

Network

NetworkもDisk IOと同じ一面があり、Networkで詰まった結果、全体の処理が詰まったりする。
また、無駄に転送量が多い場合にはそこでも余計なコストが発生する。

パフォーマンス計測具体例

狭義なパフォーマンス

アクセスログからの計測

狭義な意味でのパフォーマンスに関しては、Webサーバーのアクセスログで計測可能。

nginx(ltsv形式)の例

time:2015-11-07T15:08:30+09:00  remote_addr:xx.xx.xx.xx       request_method:GET      request_length:1258     request_uri:/users/sample https:  uri:/users/sample query_string:-  status:200      bytes_sent:20628        body_bytes_sent:19686 referer:-       useragent:Mozilla/5.0 (Linux; Android 4.4.4; SO-02G Build/23.0.B.1.59) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/34.0.0.0 Mobile Safari/537.36  forwardedfor:yy.yy.yy.yy    request_time:0.150    upstream_response_time:0.150

upstream_response_time及び、request_timeがパフォーマンス。
request_timeがリクエスト全体の時間で、upstream_response_timeがnginxがリクエストを渡した先のレスポンスタイム。
これを計測する事により全体としてどの程度のユーザー体験になっているのかが分かる。

パフォーマンス毎に色づけしたアクセス数グラフ。
こうやって可視化する事によりパフォーマンスが悪いアクセスが全体のどのくらいを占めているのかが分かる。
スクリーンショット 2015-10-30 10.12.15.png
引用(kibana4 nginxのアクセスログをレスポンスタイム別でグラフ化する) : http://qiita.com/kenjiszk/items/c3a5be34746d0f53ae97

ただし、むやみやたらにレスポンスの悪い物を潰す事が必ずしも効率が良いわけではなく、基本的には

レスポンスタイムの悪さ x リクエスト回数

によって改善対象を決めていくべき。
極端に言えば、深夜に一回だけバッチで叩かれる処理が30秒かかっていてもそれは運用上は問題ない場合が多い。

広義なパフォーマンス

広義なパフォーマンスを計測するにあたり以下の必要条件がある。

  • CPU使用率を計測している
  • メモリ使用率を計測している
  • DiskIOの状況を計測している
  • ネットワークの帯域を計測している

計測はしてしすぎる事は無いと思うので色々なメトリクスを取得しておくと良い。
(計測によってサービスのパフォーマンスに影響が出ない限り)

cpu使用率とサーバーの限界

単純計算によるおおざっぱな限界設定

以下の様な状況の場合。

1秒間に100リクエストをさばいた時のCPU使用率が25%だった。

CPUの上限を75%に設けた場合、1秒間に300リクエストまでさばけるだろうという試算が出来る。
当然この数字が多ければ多いほどCPUリソースを効率的に使っていると考えられる。

KPI化

限界を知る事と同時に、相対的にどの程度のパフォーマンスが出せているのかを知りたい場合には、1CPU当たりにさばいているアクセス数を追うと良い。
上の数字の例を使うと

100リクエスト ÷ 25% = 4

この数字を追う事によって、CPU効率の経年劣化、デプロイタイミングでのレスポンスの悪化などが検知出来るようになる。

メモリとプロセス数とパフォーマンス

前述したように、メモリはプロセスの数を決定する。
以下の様なunicornのプロセスを考える。

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
14227 ubuntu    20   0  723412 199568  11244 S  0.0  5.2   0:12.92 unicorn master -c /home/ubuntu/app/current/config/unicorn/production.rb -E production -D
14333 ubuntu    20   0  901884 508148   7372 S  0.0 13.2   5:41.44 unicorn worker[2] -c /home/ubuntu/app/current/config/unicorn/production.rb -E production -D
14324 ubuntu    20   0  895876 500848   7468 S 19.6 13.0   5:04.40 unicorn worker[0] -c /home/ubuntu/app/current/config/unicorn/production.rb -E production -D
14337 ubuntu    20   0  833188 368308   7376 S  0.0  9.6   5:23.65 unicorn worker[3] -c /home/ubuntu/app/current/config/unicorn/production.rb -E production -D
14329 ubuntu    20   0  745596 347348   7468 S  0.0  9.0   5:18.03 unicorn worker[1] -c /home/ubuntu/app/current/config/unicorn/production.rb -E production -D

RESが実際のメモリなので、全て足すと1.9G程度となる。

199568 + 508148 + 500848 + 368308 + 347348 = 1924220

上記の例だと、SHRが殆ど無視出来るほど小さいが、上のプロセスで言うと大体7Mくらい子プロセス間でメモリが共有されているので、1.9Gからそれを引くと本来のメモリ使用量となる。

単純計算をすると、サーバーにメモリが4G積んであれば残り2Gなので、あと4プロセスくらいは追加出来る計算となる。

プロセス数が決まるとさばけるアクセス数が決まる

アクセスログからレスポンスタイムが取得出来ていて、プロセス数をメモリ数に合わせて決めてあげると、トータルでどのくらいのリクエストがさばけるのか、が計算出来る。
以下の場合を考える。

レスポンスの平均時間 : 200ms
プロセス数 : 4

1秒間に1プロセスが処理出来るリクエスト数は

1000ms ÷ 200ms = 5リクエスト

プロセスが4つあるので、このシステムおいては1秒間に20リクエストを処理出来る計算となる。

ユーザーのクリック間隔を5秒だとすると同時に100人のユーザーのアクセスを受け付けられるという計算となる。

注意

この計算はレスポンスの平均値を使っているためある程度の誤差を含んでいる。
例えば、平均から大きく外れたパフォーマンスの悪いリクエストが一時的に大量に発行された場合にはさばけるユーザー数は少なくなる。

IOの限界

DiskIOは使用しているマシンによって上限が異なるので、自分が使っているマシンの限界を知っておく事が大事。

最近だとAWSを利用する事が多いと思うので、IOを気にする様なサーバーの場合には、IOPSを指定してEBSを利用すると良い。

手元のdockerにcapistranoでdeployしている時の様子をvmstatで観察する。

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 2846116  86716 592004    0    0     0     0  993 1530 12 14 74  0  0
 1  0      0 2834712  86716 592004    0    0     0     0  975 1504 12 14 74  0  0
 1  0      0 2824008  86716 592004    0    0     0     0  993 1531 13 13 74  0  0
 1  0      0 2817452  86716 592004    0    0     0     0 1008 1518 12 14 74  0  0
 1  0      0 2801844  86724 592004    0    0     0  1180  669  795 20  6 74  0  0
 1  0      0 2761792  86724 592004    0    0     0     0  777 1020 21  4 75  0  0
 0  1      0 2755536  87800 594472    0    0  1068  6504 2114 3666  5  8 75 13  0
 1  0      0 2737108  88096 603800    0    0  9176  1824 2416 4018 10 10 74  7  0
 1  0      0 2714664  88096 614592    0    0 10768     0 2433 4057 13 10 74  3  0
 1  0      0 2700948  88096 615104    0    0     8   212 1675 2916 18  8 74  0  0
 1  0      0 2694468  88096 615040    0    0     0    24 1356 2366 19  7 74  0  0
 1  0      0 2692980  88096 615172    0    0    96    56 1335 2173 19  7 74  0  0

ディスクの書き込み量を見る場合には、bi boを見ると良い。
bi : デバイスから読み込み
bo : デバイスに書き込み

ディスクへの書き込みでcpuが待たされている状況を確認するにはcpuのwaをみる。
上の例だと一時的に処理が遅れている事が分かる。

理想型

  • メモリを共有出来るだけ共有してプロセスを挙げられるだけ挙げる。
  • CPUネックにする

基本的にチューニングを進めていくとCPUネックになっていく。

プロファイラ

実際に遅いリクエストが特定出来た場合に詳細を追う為のツール。
あとで詳細追記しようと思う。

可視化

td-agent, fluentd, kibana, elasticsearchで色々と可視化中。
再掲 : http://qiita.com/kenjiszk/items/c3a5be34746d0f53ae97

Tool達

よく使うツールとかまとめ

vmstat

cpu, memoryの状況確認するコマンド。
リソースが枯渇している様な状況では大体ここに変化が現れる。

top

起動しているプロセスを確認する。
サーバーが急に重くなったりした時にはとりあえずtopを打つ。
Shift + m でメモリ使用順に、
Shift + p でCPU仕様順にソート出来るので結構便利。
top自体も実はちょっと重かったりする。

pt-query-digest

MySQLで実際に発行されいているクエリを整形して出力してくれるツール。

kenjiszk
インフラエンジニア 1年ほどiOSに浮気していましたが最近またインフラやってます 最近はRubyとGoもいじってます
http://kenjiszk.hatenablog.com/
finc
健康寿命を伸ばすアプリFiNCの開発・運営を行うモバイルヘルステクノロジーベンチャー
https://finc.com
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした