A Bunch of Great Strategies for Using Memcached and MySQL Better Together - High Scalability -
The primero recommendation for speeding up a website is almost always to add cache and more cache. And after that add a little more cache just in case. Memcached is almost always given as the recommended cache to use. What we don't often hear is how to effectively use a cache in our own products. MySQL hosted two excellent webinars (referenced below) on the subject of how to deploy and use memcach
Performance At Scale With Amazon Elasticache のまとめ
Performance At Scale With Amazon Elasticache は Amazon が書いている Elasticache に関するドキュメントなのですが、Elasticache に限らずインメモリキャッシュを使用するときのベストプラクティスを学ぶ参考になりそうだったので、ざっと読んでまとめてみました。 Elasticache 自体は ストレージエンジンとして Memcached と Redis を用意していますが、ここでは主に Redis に注目しています。 Abstract キャッシュ用途としてのインメモリキーストア 頻繁にアクセスされるようなデータをキャッシュすればアプリケーションのパフォーマンスを上げることができる 正しく使えばスケールアップ時のコストを抑えることができる キャッシュだけではなく analytics や recommendation engin
全データ型対応の操作 — redis 2.0.3 documentation
全データ型対応の操作¶ EXISTS(key)¶ 計算時間: O(1) 指定されたキー key が存在するか確認します。存在する場合は”1”が返ります。存在しない場合は”0”が返ります。キーに対応する値が空文字列でも”1”が返ることに注意してください。 返り値
HTTPヘッダのETagについて、利用想定を考えてみる。 - maachangの日記
HTTPのキャッシュについては、HTTPのレスポンスで「Last-Modified」を定義すれば、次にキャッシュされたクライアントからのリクエストに対して「If-Modified-Since」がセットされるので、そのコンテンツの日付と比較して、OKならば、HTTPステータス304（そのコンテンツはキャッシュされています的なもの）を返せばOKと言う、考えだった。 また、動的コンテンツは、絶対にキャッシュをとらないように「Cache-Control：private, no-cache, no-store, max-age=0」とか「Expires：Thu, 01-Jan 1970 01:00:00 GMT」とか「Pragma：no-cache」とかをHTTPレスポンスヘッダに設定していた。 かなり以前のJavaが1.3ぐらいの時代の話だけど、そのときに開発していたとき、下手に動的コンテンツをキ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
