さんと、チーム「スギャブロエックス」で出場して、入賞もならず、最終結果5位で終わりました。お題WebSocketで通信しつつ各ルームで複数のユーザが操作するので同期をとりながら値を更新していく、的なもの。チームの動き予選のときと同様に、言語はNode.jsを選択。それを中心に進めていくことに。実際、TSLintが良く効いて構文エラーや簡単な型の不一致などはすぐに気付くことができて編集しやすくて良かったです。ローカル環境で動かせることの確認、コードの確認など。参照だけで更新のない数レコードだけのm_itemテーブルを使わないよう定数化して排除する、くらいのところから始める。kazeburoさんによる変更も。そこを完全に任せてもらい改善の作業をすることに。元のコードはこんな感じ。buyingAtの情報を元に、1000ms後の状態をシミュレーションする、というもの。掛け算に変換すればいいだけ。それだけは逆算して割り算で求める。buyingAtがあるときも処理していかなくては、と大幅に変更をしていく。「addingAtがあった時刻」or「buyingAtがあった時刻」だけ必要な更新をして、その間の区間はtotalPowerが加算されるだけだから掛け算で加えていく、という形。最終的なコードは以下のようになった。}currentTimeからその1000ms後までの区間で、addingAtとbuyingAtがあった時刻を時系列に並べ、その区間ごとに前のイベント時刻との差分を使って掛け算でtotalMilliIsuに加える値を計算。用意されていたユニットテスト(めっちゃ有り難かった)も通った、のが14:40。これでどうだ!と走らせてみると負荷走行前のバリデーションに失敗しました。試しにitemOnSaleのtimeの値を+1してみたりしたけどやっぱり通らず(当たり前か。この時間は無駄だったな...)、思った以上にバリデーションが細かくチェックしていた。直したり負荷走行中のバリデーションに失敗しました。実はtotalPowerの値は小さくてaddingAtで大きく加算されたことによって購入可能になった場合もあるな、ということに気付いて直し。割り算も単純に割ってたらダメで小数は切り上げないといけない。これが境界値バグだった、のに気付いたのは一番最後だった。divとmodで分けて計算して、modが0より大きかったらdiv+1に...と修正。結局3時間くらいここにかかってしまった...。スコアは20,000点を越えるようにはなったけど、そこまですごいブレイクスルーにはならなかった。itemのgetPrice(count)やgetPrice(count)はcountの値が同じなら同じ値を返すだけだしキャッシュしていこう、と一度計算したものは記憶させてそれを返すように、など。あとで気付いたけどこういうのはinitialize時にある程度の数まで計算してしまえば走行中に計算するのは1回も無くなるんだった。そこから大幅な改善も出来ず、あとは2人の作業を見守るだけ、みたいな感じになってしまった。反省インフラよりアプリケーション寄りの問題だったので、主にアプリケーション担当として参加させてもらっている以上はもっとバリューを出していかなければダメだった。インメモリ化してMySQLから離れる施策も検討できたかもしれないし、他にもチューニングしていける箇所は改善していけたはず。すごい時間かかってしまったし...。どこを最優先で減らしていくべきかをちゃんと分析できていなかった、というのもある。各所でどんな値が流れていてどんな処理が時間とCPUを食っているか、を意識して調査しながら解決していく姿勢・技術が必要だった。アプリケーションエンジニアとしての力不足を痛感する敗戦でした。まとめやれるだけのことはやったけど力不足でした懇親会では色んな方と反省会しながらお話できて良かったです。ISUCONケーキめっちゃ美味しかった。...2018-10-09学習済みMobileNetV2モデルによる推論をTensorFlow.jsとWebWorkerを使っ...将棋駒画像分類の話の続き。聴きに行った先週の話ですが。