chouett0's note

掃きだめ的なsomething

ISUCON7で予選落ちした話

はじめに

先週の土日で行われたISUCON7に「インターネットは爆発しました」と言うチームで出場しました。
今回がISUCON初参加だったので参加しての感想とそのWriteupがメインの記事となります。

やったこと

僕の所属していたチームでは、3人中2人がサーバ担当、残りの1人でコードのチューンを行うと言う分担を行いました。
今回の競技ではメインで実行されていたアプリケーションはPythonのようでしたが、PHPに切り替えてチューンを行うことにしました。 補足として、PHPでのオリジナルコードのベンチマークスコアは「6000」でした。
やったこととして、まず始めに

パフォーマンス1000%UP!PHPでMySQLのDB処理を行うと重いときに行うパフォーマンス施策~基礎編~

この記事を参考にコード内のSQLクエリの命令をバッククォートで囲みました。
具体的には

SELECT UserName, Pass, ScreenName FROM UserList WHERE UserName = "hogehoge"

と言うようなクエリがあった場合

SELECT UserName, Pass, ScreenName FROM UserList WHERE UserName = "hogehoge"

と言ったように、テーブル名や要素名をクォートで囲むことで無駄な処理が減り、今回のように数千単位のデータを扱う場合では有効なようです。 さらに、今回のコードではいくつかの機能別に関数を定義しておきそれを別関数内で読んでいる構造をしているためなのか
DBからデータを取得する際に「*」で全フィールドを取ってきていたので、各関数で必要なフィールドを書き出して必要最低限の
データのみを処理するように変更しました。
ひとまずはこれでSQL部分のチューニングはいいだろうと考え、今度はコード全体を眺めていくと、「str_replace」と言う関数を使っている処理を発見しました。この関数でもまったく問題なく動作するのですが、どうやらこの関数はあまり速度的に速く無いようだったため
「strtr」と言う関数へ変更しました。

たったこれだけのことにかなりの時間をかけてしまいましたが、たったこれだけで最終スコアは20000代に跳ね上がり、約4倍の高速化を行うことができました。
それもサーバサイドのチューニングを一切行なっていなかったのでSQLがかなりのボトルネックになっていたのだろうと感じました。
もしこれでサーバサイド、そして記事内で触れていませんでしたが画像呼び出しがSQL内のバイナリを変換して画像化すると言う処理をしている影響で 見て分かるほど処理が重たくなっていたので画像の実ファイル化を行えていればもしかすると今回のボーダーの40000点も超えられたのかなと感じました。

まとめ

今回は予選敗退という結果に終わりましたが、初参戦ながらもそこそこ良い結果を出せたのかなと思いました。また、今までコードチューンを 行う機会がなかったので初めて聞いたことや初めて知ったことなどが多く久しぶりに真剣に取り組んだなぁと感じました。
最近はやたら周りがCTFで盛り上がっていて萎えr...勢いについていけなくなったのもあってか、ISUCON非常に熱いなと感じたので来年も参加したい。