nginxパフォーマンスチューニング〜静的コンテンツ配信編〜 - Qiita
今回はHTMLやCSS、Javascriptといった比較的軽量な静的コンテンツの配信をnginxでやるケースに絞ってチューニングする際のポイントについて紹介しようかと思います。 (注：worker_rlimit_nofileやsysctl.confのネットワーク周りの設定のような定石的なチューニングについてはあえて解説しないのであらかじめご了承ください。) コンテンツをgzip圧縮する 何はともあれgzip圧縮です。ネットワーク帯域に比べればCPUリソースなんて安いものです。 しかし、多くの場合これだけでは十分ではありません。何故ならnginxはデフォルトではContent-Typeがtext/htmlのコンテンツしか圧縮しないためです。圧縮対象のContent-Typeを増やすにはgzip_typesを使います。 単純なWebサイトであれば上記の設定で十分ですが、場合によってはappli
nginx で gzip_static と gunzip を使ってストレージを節約する - 酒日記 はてな支店
一月ほど前に 社内Gyazoの画像をAmazon S3に逃がしてスケーラブルに運用する - 酒日記 はてな支店 というエントリを書いて一段落と思いきや、そのサーバには社内向けの nopaste アプリも同居しており、気がつけばテキストファイルが10GB以上積もっていたのでした… 社内 nopaste アプリの実装はDBなどを使用せず単にテキストファイルを保存しているだけだったので、ファイルを gzip して nginx の http_gzip_static_module を使って配信したらディスクを節約できていいんじゃないか、と思いついたのですが、Accept-Encoding: gzip でないクライアントからアクセスすると 404 になってしまうので圧縮前のファイルが消せない。 今時ブラウザで対応していないものは少ないとはいえ、curlとか各種言語のHTTPクライアントでアクセスする場
コンテンツキャッシュとVaryヘッダとnginx - Qiita
Varyヘッダは前段のキャッシュサーバに対して、指定したヘッダの内容ごとにキャッシュを分ける必要があることを伝えるためのものです。例えばサーバがVary: Accept-Encodingをレスポンスヘッダに付加しておくと、キャッシュサーバはAccept-Encodingヘッダの内容に応じたキャッシュを保持します。 こうすることでクライアントのAccept-Encodingヘッダの内容に応じたキャッシュデータをキャッシュサーバは返すことができるというわけです。 nginxにおけるgzip圧縮とVaryヘッダ さて、本題です。上記のような事情からかApacheのmod_deflateやh2oなんかはコンテンツのgzip圧縮を有効にすると、自動的にVary: Accept-Encodingをレスポンスヘッダに付加します。一方我らがnginxは設定ファイルにgzip_vary on;と書かないとV
Memcached 1.4.19 to 1.4.28: Eviction 不具合による Slab OOM
はじめに Memcached を運用中に、Request の傾向は変わっていないにもかかわらず、徐々に Item 数が増加し始め、 ある時を境に Item が 一切 Eviction/Expire されなくなり、Memory が枯渇し Slab OOM Error が起こる、という不具合に遭遇しました。不具合の原因については特定し、1.4.29 で修正がマージされました (Pull-Request: fix zero hash items eviction , ReleaseNote1.4.29) 。不具合が発生する条件、原因、回避策を簡単にまとめておきます(Pull-Request にはより詳しく書いてあります)。 不具合が発生する条件 Memcached Version : 1.4.19 から 1.4.28 SET した Key を GET しない場合がある Item を入れ替える C
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
