ISUCON11予選参加記 (12位)

ISUCON11予選に チーム「焼肉ジャンボチキン」で参加して213593点で12位でした。

以下やったことを簡単にまとめます。 repository は https://github.com/ichyo/isucon11q です。

10~12時

• DBとAppを分けた。
• Appを2台に増やした。
• indexを貼った。(descは意味なかった。)

create index isu_condition_jia_isu_uuid_timestamp_index
	on isu_condition (jia_isu_uuid asc, timestamp desc);

• とりあえずのmysqlの設定を足した。

innodb_buffer_pool_size=2792M
innodb_log_file_size=512M
innodb_flush_method=O_DIRECT_NO_FSYNC

disable-log-bin # for isucon
innodb_flush_log_at_trx_commit=0 # for isucon

• とりあえずのnginxの設定を足した。

• DBのコネクション数を増やした。

db.SetMaxOpenConns(128)
db.SetMaxIdleConns(128)

• getTrend内の

SELECT * FROM `isu_condition` WHERE `jia_isu_uuid` = ? ORDER BY timestamp DESC

が先頭行しか使われてないのでLIMIT 1 を加えた。

12時~14時

• ループ内のINSERTをbulk insertに変えた。

_, err = tx.NamedExec("INSERT INTO `isu_condition`"+
		"	(`jia_isu_uuid`, `timestamp`, `is_sitting`, `condition`, `message`)"+
		"	VALUES (:jia_isu_uuid, :timestamp, :is_sitting, :condition, :message)", conditions)

• dropProbability を0.8に変更した。

14時~16時

• MySQLの接続時URLに?interpolateParams=true を加えた。
• /api/condition/:jia_isu_uuid内の

SELECT * FROM `isu_condition` WHERE `jia_isu_uuid` = ? AND `timestamp` < ? ORDER BY `timestamp` DESC

は全行読んだあとに conditionLevel でフィルターしたあとの limit 行だけ使っている。 テーブルにあらかじめ conditionLevel を入れることで WHERE condition_level IN (...) とLIMIT ? をSQLに加えることができて速くなった。

• dropProbability を0.75に変更した。

16時~18時

• /api/isu/:jia_isu_uuid/graph 内の

SELECT * FROM `isu_condition` WHERE `jia_isu_uuid` = ? ORDER BY `timestamp` ASC

は全行読んだあとに1日分だけのデータを使っている。 WHERE ... AND timestamp >= ? AND timestamp <= ? で graphDate と graphDate.Add(24*time.Hour) を加えて高速化した。

• MySQLのslow queryなどのいらないログや e.Debug = true などを消したりした。

やったけど効果がなかったこと

• /api/isu/:jia_isu_uuid/graph は仮想時間の当日以外は変更されることがないので、Conditional Getを実装した……が、ほとんど304が返らないので意味なかった。(しかも、ベンチマークのバグに引っかかって時間が吸われた。)
• getTrendの中の

SELECT * FROM `isu_condition` WHERE `jia_isu_uuid` = ? ORDER BY timestamp DESC LIMIT 1

がループの中で呼ばれているので、1回で複数行取るようにしたが速くならなかった。

• 不要なトランザクションを消した。コンテスト中は不要かどうかわからなかったのと、点数があまり変わらなかったのでマージされなかった。

反省

• /api/trend がボトルネックっぽいときに、キャッシュを思いつかなかったのは残念。全員に同じ内容が返されるし遅延が許可されているので効果的そう。