出題担当のfujiwaraです。
ISUCON3予選にご参加いただいた皆様、ありがとうございました。 本選進出者の皆様、おめでとうございます!
おかげさまで大きなトラブルもなく、無事に2日間の予選を終えることができました。楽しんでいただけたでしょうか。
詳細については、問題作成に協力してもらった同僚 @acidlemon が解説記事を書いていますのでご参照ください
アプローチとしては大きく分けて三つあったようです。
1.のアプローチについては、今回の初期データが200MB、数万件程度でメモリに十分保持できるサイズだったこともあり、非常に高速に動作させられるようですね。 アプリケーションの変更点が大きくなるため、時間内に作り上げるのはなかなか困難だと思いますがそれをやりきって速度を出した2チームでした。
2.のアプローチですが、フロントでキャッシュするといっても、今回の設問はログイン中ユーザに配信するページにはそれぞれのユーザ名が書き込まれているなど、キャッシュすることがなかなか難しい作りです。
ただし /recent/* という投稿された一覧画面のみ、非ログイン状態のクライアントが大量にアクセスしてくる作りになっています。(一部、ログインセッションを持ったクライアントもアクセスします)
ISUCON3予選にご参加いただいた皆様、ありがとうございました。 本選進出者の皆様、おめでとうございます!
おかげさまで大きなトラブルもなく、無事に2日間の予選を終えることができました。楽しんでいただけたでしょうか。
出題内容
今回の予選問題は以下のようなWebアプリケーションを題材としました。- 要するにGithub Gistのようなもの
- ログイン機能がある。Cookieによるセッション維持が必要
- プライベート投稿機能がある。プライベート設定されたものはログインしているユーザにしか見えない
- Markdown形式で投稿できる
詳細については、問題作成に協力してもらった同僚 @acidlemon が解説記事を書いていますのでご参照ください
講評
予選参加者の皆さんから提出された AMI から運営がインスタンスを起動してベンチマークを行い、予選期間中に記録された最高スコアに近い値が計測されたのを確認して本選進出確定、というレギュレーションでしたので、こちらでベンチマークを実行しつつ内部を軽く見せていただきました。それを元に講評したいと思います。アプローチとしては大きく分けて三つあったようです。
- アプリケーションを再実装しオンメモリにデータを保持して高速に処理する実装を作り上げる
- フロント(nginx, varnishなど)でキャッシュを積極的に行い性能を出す
- アプリケーションを着実に改善していくことで性能を出す
1.のアプローチについては、今回の初期データが200MB、数万件程度でメモリに十分保持できるサイズだったこともあり、非常に高速に動作させられるようですね。 アプリケーションの変更点が大きくなるため、時間内に作り上げるのはなかなか困難だと思いますがそれをやりきって速度を出した2チームでした。
2.のアプローチですが、フロントでキャッシュするといっても、今回の設問はログイン中ユーザに配信するページにはそれぞれのユーザ名が書き込まれているなど、キャッシュすることがなかなか難しい作りです。
ただし /recent/* という投稿された一覧画面のみ、非ログイン状態のクライアントが大量にアクセスしてくる作りになっています。(一部、ログインセッションを持ったクライアントもアクセスします)
