ISUCON 5 決勝の天気APIの解説 - Qiita
ISUCON 5が終わりました。 出題担当のtagomorisさん、kamipoさん、お疲れ様でした。非常に大変だったと思いますが、お手伝いさせてもらって刺激を受けましたし楽しかったし、良い経験になりました。ありがとうございます。 941さん、各言語の担当者の方々、参加者のみなさんも、お疲れ様でした。 来年もお手伝いしたいし、いや自分自身も参加もしたいし、迷うところです。 さて、ISUCON 5 決勝での天気予報APIを実装しましたので、APIの挙動や意図などを記しておきます（全体の講評は ISUCON5 本選問題の公開と講評 をご覧ください）。 zipcode クエリパラメータとして zipcode を渡していましたが、APIはこれを見ていません。ところがアプリ側はzipcodeを渡すようになっています。 アプリ側の実装の意図については把握していませんが、おそらくキャッシュをしにくくする
Webアプリにおけるキャッシュ。オレオレ事例 - ゆーすけべー日記
Webアプリにおいて、アクセスやデータ量が多く/大きくなってくると、 バックエンドのパフォーマンスが低下しがちです。 MySQLなどのRDBMSにデータを置いている場合は適切に クエリーを改善する、インデックスを張る、といった策で解決する場合もありますが、 キャッシュを効果的に利用することでより高負荷に対応できる可能性があります。 また、外部APIへの問い合わせなど、どうしてもネットワークや他のリソースのレスポンスタイムに 引きずられる部分に関しては情報を手元にキャッシュしておくと何かとよいでしょう。 今回はWebアプリケーションのレイヤーで最近僕がどのようにキャッシュを使っているのか？ の事例を紹介しつつまとめてみたいと思います。 キャッシュについてとその基本 そもそもキャッシュとは、簡単にふわっと表現するならば、 「一時的に情報を手元の近い場所に置いておいて利用する手法、もしくはその一
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
