こんにちは。
シナジーデザイン プログラマーの Aです。
先日
代表と帰り道をご一緒した際に
「自身の仕事をブログに書いてみてはどうか」と提言を受けました。
ターゲット
・これからプログラマーとして加わるかもしれない方
・イマイチAが何やってるのかピンとこないスタッフ
目的
・バックエンド開発の一片の周知
という感じ。
今回は
「パフォーマンスチューニング」
を題材に話します。
パフォーマンス≒サービスを利用するユーザーの体感速度
前提として
そもそもの「パフォーマンス」の定義から始めます。
ここでは
「パフォーマンス」を
「サービスを利用するユーザーの体感速度」
とします。
「体感」というところが大事。
開発者から見て
そりゃ時間かかるよなぁ、というような機能でも
ユーザーから見れば知ったこっちゃない
という所が大事です。
パフォーマンスは日々落ちている
デキテルや抱きしめーるでは
機能追加やUIの改修を、毎日行っています。
毎日毎日
なんらかのコードが追加され、
サーバーやブラウザが処理する情報が増えています。
その結果
ユーザー操作の反応速度が落ちたり、
表示されるまでの時間が長くなったりしています。
もし気づかないのであればそれはとても嬉しい事。
毎日の細々としたパフォーマンスチューニングの功労、です。
パフォーマンスへの期待値は日々上がっている
一方で、
パフォーマンスへの期待値は日々上がっています。
例えばこの数年で
求められるパフォーマンスの基準はネイティブアプリになりました。
出前系のアプリとか、タクシー配車系のアプリとか。正直凄い。
そういったアプリに慣れると
昔ながらのWEBアプリの操作感にストレスが生じる。
そのストレスを軽減させる改修の1つが
パフォーマンスチューニングになります。
少し余談なんですが
違和感を覚えたときに
そもそもの基準は何だ？と考えることは
とても大事なことだと思います。
基準あっての違和感なので、
基準が分からないと違和感を言語化できない。
1秒で表示されて、初めて気づかれる。
先に話した通り
パフォーマンスチューニングは
ストレスの軽減がその目的です。
プラスを増幅させるというよりは
マイナス のものを 0 に近づけるようなニュアンスの仕事。
あんまり言うと僻みっぽくなるんですが
数倍の高速化では、あまり気づかれないです(笑)
例えば10秒かかったモノが2秒になったら5倍ですが
多分一度では気づかない。「今日ネット調子いいな」って感じ。
100秒が10秒になったら気づくかもしれないけど
「それでも遅いな」って感じ。
どういう表示であれ機能であれ
1秒くらいで表示されて、初めて「おっ」ってなるのかなと思います。
個人的な経験としては
過去に行ったチューニングで周りの手応えがあった時は
200-250倍の高速化を行いました。
推測するな、計測せよ。
具体的な開発の話をするつもりはないんですが
「推測するな計測せよ」という金言だけご紹介します。
推測してコードを調整するのではなく
とにかく具体的に計測して、一番のボトルネックを潰す。
これがパフォーマンスチューニングの基本になります。
それでも
どこを計測するのか？という勘所は
推測とか経験値でしか養われないので、
自社サービスのコードの理解、というのは
非常に重要度の高い知識だと思います。
