s平面の左側

左側なので安定してます(制御工学の話は出てきません)

ISUCON 12 でも PHP 移植を担当しました #ISUCON

本戦開催から 1 ヶ月以上経っちゃいまいたが、改めまして、今年もやりました。

意図や所感などを箇条書きで雑多に書いていきます。

isucon.net

大きな方針は ISUCON 11 のときと大きく変わらないので、こちらの発表を参考にしてください。

www.youtube.com

docs.google.com

予選(マルチテナントリーダーボードサービス)

www.youtube.com

リポジトリ github.com

移植 PR github.com

  • 例外の捕捉ある程度簡素化した
    • 途中まで昨年と同様丁寧に捕捉していた
    • SQLite のコネクションや flock などを取り扱ううえでコードがかなり冗長になり、競技者にとってノイズになりそうだったのでやめた
  • Doctrine DBAL を利用した理由
    • SQLite3 のクエリログ出力のためだけ
    • これは移植の要件として指定されていた
      • けど、このクエリログの存在に気づき活用した人はどれくらいいたのだろうか?
  • 悩みどころ
    • PSR-7 の UploadedFile の扱い(PHP ネイティブの stream に変換する方法がわからなかった)

本戦(育成型放置ゲーム)

www.youtube.com

リポジトリ https://github.com/isucon/isucon12-final

移植 PR https://github.com/isucon/isucon12-final/pull/340

  • 単純に物量が多かった
    • メインロジックが 4,566 行(予選は 1,768 行、ISUCON 11 本戦は 2,722 行)
  • 一方で変化球な仕様は特になかったのでひたすら愚直に移植していく感じ
    • 強いて言うなら ID 生成まわり
      • generateID の懸念点が他言語とは異なる
        • コネクションを使い回す他言語では「メインロジックと別のコネクションを保持しなきゃ」という感じになる
        • PHP はそもそもリクエストごとにコネクションが独立なので考慮不要(トランザクションだけ丁寧に)
        • 雑にこういうことしてもちゃんと動いちゃうのは PHP の強m(ry
  • 管理者用 API と一般ユーザ向け API に分かれている
    • 共通で使う処理は Go だと同一パッケージ内なので気にしなくて良いけど、PHP ではそれぞれ別クラスから利用されるので trait として切り出した
    • Handler の抽象基底クラスを作ってそれぞれ継承する、というのは「AdminHandler と Handler で依存関係が変わってきたらやだなー」と思ってやらなかった(結果同じになったけど)
  • PHPでは PUT メソッドでアップロードされたファイルは(通常では)扱えないんですね

所感など

今年も楽しく移植させてもらいました。

しかし毎年同じ人が移植して実装パターンが固定化してしまうのも良くないのかな?と思っており、来年以降は別の人が PHP 移植担当になってもいいなーと思います *1

また、来年あたりでふつうの PHP とは別に「PHP(RoadRunner)」とか「PHP(Swoole)」とかいう実装が出てきたら面白いなーとも思ったり。

*1:もちろん必要であれば私がやるつもりですが。