ポーリングによる状態チェックを軽量化した話

Posted at 2021-11-25

はじめに

注・最初っからそうしとけよ、という話です。

研修で使うようなゲームっぽいプロダクト(ゲームマスター:プレーヤー=1:n)で、双方が行った操作(データ変更)をお互いにある程度リアルタイムで検知するために、ポーリングを用いて定期的にチェックすることで実現していました。

ポーリングを用いたのは下記の理由によります。

さていざ実戦投入してみると、数十クライアント程度でCPUがパンパンになって、ロードアベレージが100近くまで行きました。

DBを外に出したり、ポーリング間隔をあけたりしましたが、劇的な効果は得られませんでした。

(php-fpmがアイドリングでもなぜかCPUを食いっぱなしになるという現象もあったのでそれも一因かもしれません。これはstraceで真面目に調べようと思ったら突如再現しなくなりました。)

これは根本的に対策せねばなるまいということで、どうするか検討しました。

ポーリングで返しているデータは、ゲームの状態を入れたjsonで、アクセスが来るたびにDBからデータを取ってきてPHPでデータを加工して返していました。

実はこのプロダクトのゲーム状態の変化はせいぜい分速ひと桁程度です。
そしてゲーム状態に変化がなければ当然jsonデータにも変化はなく、アクセスが来るたびにDBにアクセスして作る必要はありません。

ですので変化が起きるタイミングでスタティックなjsonファイルに書き出して、ポーリングはそのファイルにアクセスさせることにしました。これならポーリングのアクセスはnginxの階層のみで動くので、軽くなるはずです。

jsonファイルのreadとwriteがバッティングするとまずそうなので、書き込み方法は下記のようにしています。
完璧ではないかも知れませんが、少なくとも同じファイルに読み書きが同時に起こることはないので概ね大丈夫ではないかと思います。

スタティックなファイルにしてすっきり軽くなりましたが、今度は状態に変化がなくても毎回同じものが転送されるのが無駄に感じます。

ですので更新チェックを入れて、前回のアクセスと変化がない場合は304(Not Modified)を返させてbodyの転送を節約するようにしました。

これは、前回アクセス時のレスポンスのEtagヘッダの値をリクエストのIf-None-Matchヘッダの値として付けることで実現しました。