なんかかきたい

プログラミングなどの個人的なメモやサークル「ゆきいろパラソル」の情報を載せてます

ISUCON6予選問題のPHP実装を担当しました

こんにちはの方もはじめましての方もエントリーを読んでいただきありがとうございます。

昨日から開催されている ISUCON6 の予選にてPHP実装のコーディングを担当させていただきました t-cyrill と申します。 日頃はWeb屋さんでインフラのお仕事をやっています。

今回はいつものような適当なエントリーではなく少ししっかりとしたエントリーで担当しましたPHP実装について、いくつか簡単な補足をさせていただきます。

はじめに

ISUCON6予選参加者のみなさま、お疲れさまでした。 たくさんのチームの方にPHP実装を触っていただけたようでありがとうございます。

ISUCONということで多くの人に触れていただくコードになるだろうと思い、どのチームの方にも得意不得意の影響があまりないようになるべくよく知られたライブラリを使ったり、元からPHPがうまく動作するような環境を用意できるように準備したつもりです。

いくつか至らない点もあったと思いますが、もし困るところがあまりなかったようでしたら幸いです。

実装に使用したライブラリなど

composer.lockを見ていただればわかることですが、今回はなるべく初期のPerl実装に近くなるようにライブラリを選びました。

軽量フレームワークSlim3、HTTPクライアントの Guzzle6、テンプレートエンジンの Twig などPHPな方にはよく見るようなライブラリを元にして作っていきました。

Twigを選択したのは元になったPerlテンプレート内でテンプレート継承を使用していたためですが、今思えば特に必要ではなかったような気もします。

独自実装を使ったところなど

Perl実装から移す際にPHPで用意できなかったrandom_stringなど一部の関数は元の実装コードとそれほど違和感がないように独自に実装しました。 これらの関数は glue.php にまとまっています。

本質的なところではないのですが、 random_string の実装はかなり雑で、Perl実装のように柔軟なランダム文字列を生成することはできません。

pcreの制限について

webapp/Isuda/app.php の L49 に怪しげな // NOTE: avoid pcre limitation "regular expression is too large at offset" というコメントを見かけたPHPの方は嫌な気持ちになったかもしれません。

あまりこのケースに当てはまることがないので意外と知られていないかもしれませんが、PHPpreg系関数が内部で使っている正規表現ライブラリpcreにはデフォルトで渡せる正規表現パターン文字列の長さに制限があります。この制限を変更するには pcre ビルド時にオプションを指定する必要があります。

今回初期実装の通りに実装すると正規表現文字数が pcre の制限にかかります。Perl実装から移すときにここはかなり悩みました。

というのも、正規表現を使わない場合PHP実装がやや有利になってしまいますし、pcreを使うためには独自にpcreを用意する必要があり、初期ビルド以外のPHPを用意したチームが本質的ではないところでトラブルに遭遇するのは避けたかったのです。

結局、間を取ってハッシュの生成には preg_replace_callback を分割した正規表現で複数回呼び出して生成し、本来の置換処理はループ後の strtr にてまとめて行うように実装しました。

余談ですが、Perl実装の動作は正規表現のevalでPHPでは廃止された機能です。

Slim Containerの拡張

細かなところですが各エンドポイントで $this->dbh$this->htmlify のような呼び出しを実現するため、$app コンテナを継承した独自のSlim Containerを用意しています。

PHP7で入った無名クラスの機能をこのような形で使えたのは少し面白かったです。

stash

Perlではテンプレートへの変数渡しにstashを使っており、これを模倣するためコンテナのPimpleを直接突っ込んでおきました。

Slimの依存に含まれていたのでいい感じの入れ物として使いましたがこういう使い方は普段しないのであまりよくないような気もしています。

実装ミスについて

途中で気付かれたチームから報告がありましたが、初期のPHP実装にはベンチマーク結果に影響のない2つのわかりやすい実装ミスがあります。

一つは nginx.php.conf での mime.types ロード忘れでブラウザで閲覧した際に多くのブラウザでスタイルが適用されないなど見た目の問題が発生します。

+    include       mime.types;
+    default_type  application/octet-stream;

もう一つは POST keyword/keyword を呼び出すと必ず500エラーが発生するというもので、ミドルウェアの指定個所に間違いがあります。 また、同エンドポイントはkeywordのパース方法も間違っています。

- $keyword = $req->getParsedBody()['keyword'];
+ $keyword = $req->getAttribute('keyword');

- })->add('authenticate')->add($mw['set_name']);
+ })->add($mw['authenticate'])->add($mw['set_name']);

しかしながら、ベンチマーカーはPOST keyword/keywordが成功するのを試さないので、ベンチマークの結果に影響はありませんでした。

ベンチマーカーがPOST keyword/keywordを試していないことが公開になると他言語実装でも有利になってしまいますし、(特に1日目2日目で情報が違うことになる)

ベンチマークの結果自体には影響のないものでしたので、ルールにのっとり「ベンチマーカーの結果が全てです」という回答としました。 GoやPython実装のバグとは違いこのバグに対してパッチを提供しなかったのはこのような理由です。

2点ともすぐに気づけるようなミスなだけにPHP実装を試していただいた方には申しわけなかったです。

初期実装のサーバについて

初期実装のサーバは予選時には nginx + phpfpm の構成としました。

もともとはビルトインサーバを使用して簡単に呼び出す予定でしたが、並列処理性に問題があるためベンチの初期チェックを通過できなかったため、Ruby実装がunicornを用意したタイミングでphp-fpmを使うようにsystemd unitを置き換えました。

pmも"static"に設定されたのでPerlほどではありませんがPHPの初期スコアはそれなりに出るようになっていたと思います。

実装の最適化について

いくつかのチームから解説が出るでしょうし、PHP実装もそちらを参考にしていただければ同じように速くなりますが、初期実装でわざと遅くなりそうにした個所のみ補足します。

PHP-FPMのtcp呼び出し

初期実装で php-fpm90009001 ポートでlistenしており、nginxからプロキシする形で用意されています。 php-fpm にはunix domain socketでlistenする機能がありますので置き換えることでパフォーマンスがわずかに改善します。

最後に

本選でPHP実装を担当することはおそらくありませんが、本選でもPHP実装が上位チームに入ってくれることを期待しています。 それでは本選でお会いしましょう。