はてなブログでSREをやっているid:cohalzです。 2019年12月頃からid:utgwkkやid:onkとともに、はてなブログにおけるキャッシュ周りの改善を行いました。その結果、次のような成果が得られました。 ブログ記事のキャッシュヒット率が、1日平均で8％から58％に向上 アプリケーションサーバの台数を、以前の半数以下に削減 DBに届くリクエスト数が、以前の3分の2まで減少 レスポンスタイムの平均が、以前の8割まで減少 この記事では、実際にどういった改善を行ったのか、その際に気をつけたことや大変だったことを紹介します。 はてなブログがVarnishを導入した経緯と課題 開発合宿をきっかけに問題が明らかになる 進め方をまず考える ホストのメモリをできるだけたくさん利用する メモリを積んだホストでなぜかレイテンシが悪化 キャッシュが分散しないようVaryヘッダを使う デバイス情報を適
こんにちは。プロダクト開発部のサーバサイドエンジニアの荒川です。普段はSansanのスマホアプリのAPIの開発をしています。 今回扱うテーマは皆さん大好きキャッシュ（Cache） です。 Webアプリケーションを開発するエンジニアである以上、キャッシュの存在からは逃れられないでしょう。 例えばパフォーマンスを向上させる手段として、キャッシュを仕込むことは往々にしてあるかと思います。 キャッシュを使えばパフォーマンスが向上しそう、というイメージも強いため安易に選択する戦略になりがちですが、正しく扱うことは本質的に難しいです。 しかしキャッシュを上手に使えば、ユーザ体験を圧倒的に向上させることができます。 そんな諸刃の剣キャッシュ💰について考慮するべきこと、その戦略を改めてまとめてみました。 今回の対象 今回の対象は、アプリケーションレベルでのキャッシュ戦略を取り扱います。 いわゆるキャッシ
Yes, you read that correctly. In this post, I’ll tell you how we’ve implemented “PHP file caching” in our application logic at Graphiq, resulting in crazy-fast cache reads. The core of the technique is leveraging the PHP engine’s in-memory file caching (opcache) to cache application data in addition to code. HHVM has supported this technique for a few years, but PHP only recently started supportin
概要 Webフロントのパフォーマンス診断 - Carpe Diem で指摘されたブラウザキャッシュの対応をするため調べてみました。 大きく分けて強いキャッシュと弱いキャッシュの２種類のキャッシュがあります。 強いキャッシュ ブラウザ側でリソースを保持し、期限が切れるまでサーバにHTTPリクエストを発行しません。 なので一度ブラウザにキャッシュされるとサーバ側からハンドリングすることができなくなります。 これを設定する方法は Cache-Controlヘッダー Expiresヘッダー の２つがあります。 Cache-Control: max-age サーバからのレスポンスで以下のようにCache-Controlヘッダーを付けます。 Cache-Control: max-age=3600 このヘッダーが付いたリソースはブラウザ上では強いキャッシュとして残ります。 max-ageは秒数なので、こ
Redis を LRU キャッシュとして使う¶ Redis をキャッシュとして使う際、新しいデータを追加するときに自動的に古いデータを追い出すようにできると便利です。この振る舞いは、人気の高い memcached システムのデフォルトの振る舞いであるため、開発者の間では非常によく知られています。 LRU は、実際にはエビクション・メソッドのひとつにすぎません。このページでは Redis のメモリ使用量を制限するための ‘maxmemory’ ディレクティブについて、より一般的なトピックを扱います。また、Redis で使用されている LRU アルゴリズムについても扱います。Redis の LRU アルゴリズムは、実際には正確な LRU ではなく、その近似です。 メモリ設定のためのディレクティブ¶ ‘maxmemory’ ディレクティブは、データセットに対して指定された量のメモリを使用するよう
YAPC::Asia Hachioji 2016 mid in Shinagawa 2016-07-03 Yusuke Wada a.k.a. yusukebe
https://github.com/nazo/safeapc なにこれ？ APC(APCu)のユーザーキャッシュ（アプリから指定するキャッシュ。ソースコードのキャッシュではない）を「そこそこ安全に」扱うための簡単なラッパーです。 どう使うの？ packagistに登録してあるので普通にcomposerから入れてください。 基本的には普通にapc_fetchとかするのがSafeApc::get等に変わっただけです。 あと、リクエストの最初に、以下を入れる必要があります。 // キャッシュで使用するリクエスト開始時間を指定 SafeApc::setCacheStartTime($_SERVER['REQUEST_TIME']); // キャッシュのバージョン番号を指定（この例では外部ファイルから） SafeApc::setCacheVersionKey(file_get_contents('
さてAPCuを使うようになり、まず気になるところがキャッシュと云えど限界はある。 そう、apc.shm_sizeだ。 毎回悩ましいのが、どれくらいの容量を設定していればいいのか。 実際にはttlに設定されている(実際にはプログラム上で明示的に指定するのだけど)時間でクリアされるため そこまで大きなメモリを確保する必要はない、けれども、一体どれくらいを設定したらいいのか。 更に言うと、設定したメモリを超えてしまった時、どういったことが起きるのか。 今回のAPCuはCSVデータを保存しておく（消えても問題ないようなデータ）ことが利用目的です。 どれくらい確保するかについては実際保存するだろうCSVデータなりを運用することを想定として多めに作成し、実際にAPCuに保存した上で容量を確認すれば問題ないかと思っています。 もちろんバッファも考えて多めに確保はします。 問題はその想定を超えて、オーバフ
最近じゃmemcachedを活用してデータベース(RDB)の負荷を下げるって話、そこらじゅうから聞こえてくるけれど、memcachedの活用は、格納オブジェクトの”粒度”（granularity）がキモだと思ってます。 memcachedは、KeyとDataをペアで格納して、Keyが与えられると、関連付けられたDataを返すだけのシンプルなシステム。PerlやPHPの連想配列と同じ。このmemcachedをRDBのキャッシュとして活用してやる場合、memcachedに格納するキャッシュデータの単位、”粒度”をどう設計するかが重要になってくる。 RDBの場合、格納されるデータはRow(レコード)単位。じゃぁキャッシュもRow単位で作ってやればいいのかといえば、それではうまくいかないケースもたくさんある。RDBでは専用の問い合わせ言語であるSQLを使って、 SELECT * FROM hoge
このエントリは闇PHP Advent Calendar 2015の3日目です。なぜか@do_akiさんによる4日目の記事「ZEND_TICKS と tick 関数」を読んだ後で書いています。 本稿では、あまり日本語での説明を見たことがないPHPのインターン化文字列(interned strings)について紹介します。 文字列のインターン化とは 文字列のインターン化というのは多くのプログラミング言語で採用されているテクニックで、同じ不変文字列がプログラム中に何度も登場するような場合に、毎回文字列をコピーするのではなく同じ文字列を共有することで実行時間やメモリ消費量などを有利にするようなものです。Wikipediaの「String interning」なども参照してください。 internというのは軍などで使われる単語で、抑留というのが日本語で一番近い単語だと思いますが、どうもピンとこないの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
