はてなブログのキャッシュ周りをきちんと改善したら、アプリケーションサーバの台数を半分にできた話 - Hatena Developer Blog
はてなブログでSREをやっているid:cohalzです。 2019年12月頃からid:utgwkkやid:onkとともに、はてなブログにおけるキャッシュ周りの改善を行いました。その結果、次のような成果が得られました。 ブログ記事のキャッシュヒット率が、1日平均で8％から58％に向上 アプリケーションサーバの台数を、以前の半数以下に削減 DBに届くリクエスト数が、以前の3分の2まで減少 レスポンスタイムの平均が、以前の8割まで減少 この記事では、実際にどういった改善を行ったのか、その際に気をつけたことや大変だったことを紹介します。 はてなブログがVarnishを導入した経緯と課題 開発合宿をきっかけに問題が明らかになる 進め方をまず考える ホストのメモリをできるだけたくさん利用する メモリを積んだホストでなぜかレイテンシが悪化 キャッシュが分散しないようVaryヘッダを使う デバイス情報を適
Avoiding instruction cache misses
Avoiding instruction cache misses21 June 2019Modern processors are quite complex, with many parts having the potential to become a bottleneck. It is relatively easy to reason about the performance of short pieces of code, especially if memory effects are kept to a minimum. Both static analysis tools like LLVM MCA and microbenchmarks can provide a lot of information in such cases. However, the beha
Adaptive replacement cache（ARC）とはどんなものか調べてみる - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
パフォーマンスに関するスライド「What Linux can learn from Solaris performance and vice-versa」を見ててARCって単語が出てきて参照カウンタ？と思ったんだけど調べてみたらAdaptive replacement cache（ARC）のことだったので調べてみた。英語版のwikipediaに解説が合ったのでそれベースで。USENIXに論文があるけどこれを今読む気力がないので今度読む。 このARCは何かというとキャッシュなんかでよく使われているLRUの発展形のようで、LRUが単純に最近使ったものだけを管理しているのと違って以下のように4つのデータを管理する T1:一度アクセスされたもの T2:T1にあるデータが2回目にアクセスされた時にこちらに移動する B1:T1にあったけど最近アクセスがなくてT1から追い出されたもの B2:T2にあった
bliki: Two Hard Things
There are only two hard things in Computer Science: cache invalidation and naming things. -- Phil Karlton Long a favorite saying of mine, one for which I couldn't find a satisfactory URL. Like many good phrases, it's had a host of riffs on it. A few of them I feel are worth adding to the page There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors. --
Railsアプリを66％スピードアップ ― Railsキャッシュの完全ガイド | POSTD
(訳注：2016/3/2、頂いた翻訳フィードバックをもとに記事を修正いたしました。) Railsアプリでのキャッシングは、「たまに夕食を一緒にするけれど、本当はもっと頻繁に一緒にいるべき友達」に少し似ています。パフォーマンスをまじめに考えるRailsアプリのほぼ全てで、もっとキャッシングを使えるはずですが、ほとんどのRailsアプリでは、完全にキャッシングを避けています。それでも普通は、Railsで高速なサーバ応答を達成するための唯一の道は、キャッシングの知的な利用なのです。約250msの応答時間を、簡単に50～100msに高速化できます。 定義についての注意 ― この記事は、アプリケーション層のキャッシングのみを対象としています。HTTPキャッシング（これは全く別の難物で、あなたのアプリケーションに実装する必要はありません）は、別の機会で扱いましょう。 するべきキャッシングをしない理由
[rails][dalli] Rails と dalli で raw データを書き込む術 - HsbtDiary(2014-03-14)
■ [rails][dalli] Rails と dalli で raw データを書き込む術 Rails で dalli を使ってキャッシュデータを書き込む時は下のようにするけど Rails.cache.write(key, val) この方法だと Rails の ActiveSupport::Cache::Entry クラスが使われるけど、別の言語で書かれたバックエンドから参照する時は raw データを書き込みたい。そういう時は Rails.cache.dalli.with do |client| client.set(key, val, nil, raw: true) end というように、with をブロック付きで呼び出してからオプションとして raw: true を渡すと raw データを書き込むことができる。memcache-client の時は Rails.cache.writ
![[rails][dalli] Rails と dalli で raw データを書き込む術 - HsbtDiary(2014-03-14)](https://cdn-ak-scissors.b.st-hatena.com/image/square/8cab6183abe73ade0ce0a24c302ac36ee5c17b43/height=288;version=1;width=512/https%3A%2F%2Fwww.hsbt.org%2Fdiary%2Ftheme%2Fogimage.png)
とある CMS を使ったサイトに Varnish を導入した話
Shin x blog Advent Calendar 2013 の 6 日目です。 とあるサイトに、Varnish をリバースプロキシとして導入して、半年が経過しました。 導入した経緯やその効果など書いてみたいと思います。 Varnish とは Varnish は、HTTP アクセラレータです。Web サーバのリバースプロキシとして動作し、キャッシュを生かして高いパフォーマンスを発揮するのが特徴です。また、VCL という独自の設定言語を持ち、これにより状況に応じた設定を柔軟に行うことができます。 導入の経緯 このサイトでは LAMP 構成の CMS を利用しており、インフラには AWS を利用しています。基本、閲覧が中心なのですが、イベント時に多数のアクセスがあります。S3 や CloudFront も検討したのですが、コンテンツを数分おきに更新する必要があるので今回は採用しませんでした
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
