NginxでWebサーバ間をトレースするrequest_id - Qiita
$request_id Nginx 1.11.0 以降に限りますが、リクエスト毎に発番されるIDの変数として $request_id が追加されたようです。 http://nginx.org/en/docs/http/ngx_http_core_module.html#var_request_id この変数を利用することにより、Nginxコアだけでサービス間のトレースを簡単に行うことが可能になります。 シンプルな例 以下のように、$request_idをログに含めるだけでリクエスト毎のIDを記録できます。 http { log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "
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
【nginx】レスポンスタイムアウトの設定メモ｜ばちブロ
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。 ちょっとしたメモ代わりに。 割と重要で、なかなか参考になるものがなかったので。 以下3つの設定値について、ちょっと調べてみました。 proxy_connect_timeout proxy_send_timeout proxy_read_timeout 参考書などの説明によると、各設定値はこんな感じの説明をされていました。 ■proxy_connect_timeout バックエンドサーバとの接続タイムアウト時間の指定 バックエンドサーバに接続要求を送り、n秒間接続できない場合発生 すでにバックエンドと接続されている場合、このタイムアウトは発生しない ■proxy_send_timeout バックエンドサーバへのデータ送出のタイムアウトの秒数を指定 このタイムアウトは、応答全体の遅れ
200万 Webサイトを支える ロリポップ！と mruby
200万以上のWebサイトを支えるインフラで、リソース制御として使われている mod_mruby の採用事例を紹介します。
nginxでもapacheでも使えるDoS的アクセスを検知して任意の制御をするWebサーバ拡張をmrubyで作った - 人間とウェブの未来
github.com 会社の運用メンバーと色々議論していた中で、「カジュアルにWebサーバへのDoSみたいなアクセスが来た時に検知して制御したいよねー」という話が上がったので、http-dos-detectorというnginxでもapacheでも使えるWebサーバ拡張をmrubyで書きました。 もちろんmrubyなので、mod_mrubyとngx_mrubyを使っています。ので、Rubyコードはそのまま同じコードをどちらのミドルウェアでも使えます。mod_mrubyとngx_mrubyを使えば、ちょっとしたWebサーバの拡張は両方で同じ実装に落とし込めるので便利ですね。 使い方 例の如く、GitHubのREADME通りにインストールして下さい。Rubyのコードはmod_mrubyでもngx_mrubyでも有効なので、そのコードを読み込む設定をそれぞれ以下のように記述するだけでよいです。 a
Nginx Optimization: understanding sendfile, tcp_nodelay and tcp_nopush
This article a is translation by popular request of Optimisations Nginx, bien comprendre sendfile, tcpnodelay et tcpnopush I wrote in French in January. Most articles dealing with optimizing Nginx performances recommend to use sendfile, tcp_nodelay and tcp_nopush options in the nginx.conf configuration file. Unfortunately, almost none of them tell neither how they impact the Web server nor how the
Shibuya.pm#17でnginxの話をしました - 考える人、コードを書く人
speakerdeck.com Shibuya Perl Mongersテクニカルトーク#17にお呼ばれしたのでnginxの話をしました。(なんとShibuya.pmは初参加です) 発表直後にちょっと私事でバタバタした関係であまり集中して他の方の発表を聞くことができなかったのが少し残念ですが、 あらためてh2oすごいなーって思った一日でした。 HTTP/2やSPDYのprioritizationについては僕は元々少々懐疑的で「これ、自分でチューニングしたくないなぁ」と思っていたのですが、なるほど、サーバ側で全部やってしまうのもアリかと思った次第です。 あと、発表の最後でも軽く触れましたがYAPC::Asia Tokyo 2015に実践nginxモジュール開発〜CとLua〜というトークで応募しています。採択されたらngx_small_lightやngx_dynamic_upstreamの開発
net::ERR_INCOMPLETE_CHUNKED_ENCODING with Nginx - ネットの海の片隅で
起こったこと Rails/Unicorn/Nginxという構成で動いているアプリケーションを使っていたら、net::ERR_INCOMPLETE_CHUNKED_ENCODINGというエラーが発生し、32KB以上のページが途中で途切れるようになりました。 解決策 その1 Railsのログを追ってみたところ特に異常なし。Unicornも特に異常はなく、試しにNginxを介さずにUnicornに直接アクセスするとページが切れずに表示されました。したがって、犯人はNginx。 そこで、いろいろとググってみたところ、こんなものを発見。 git - Enabling nginx Chunked Transfer Encoding - Server Fault というわけで、Nginxの設定ファイルに追記します。*1 location / { proxy_buffering off; } 細かいことを
HTTP2 時代のサーバサイドアーキテクチャ考察 - Block Rockin’ Codes
update 色々と twitter で議論が起こったのでまとめて貼っておきます。 togetter.com みなさんありがとうございました。 intro HTTP2 の RFC 化も目前ということで、そろそろ実際に HTTP2 を導入していくにあたってサーバサイドの構成についても、具体的にどう変わっていくかという点を考え始めていく必要があります。 そんな話を @koichik さんとしていたら、色々と考えが膨らんだのでメモしておきます。 前提 今回は、中規模のサービスを想定し、特に HTTP2 のサーバプッシュを踏まえた上でのコンテンツ配信などに、どういう構成が考えられるかを考えていきます。 また、本エントリ内では独自に以下の表記を採用します。 HTTP/1.1 = HTTP/1.1 (平文) HTTP/2 = HTTP/2 (平文) HTTPS/1.1 = HTTP/1.1 over
app serverがリクエストの処理にかかった時間をログに記録する
Webアプリケーションのパフォーマンスをトラッキングするために、app serverの処理にかかった時間を記録したい。 方法を、以下のように分類できる。 1. reverse proxy側で、proxy先のapp serverがレスポンスを返してくるのにかかった時間をログに記録する場合 1.1 nginx 1.2 apache 2. app serverでリクエスト処理にかかった時間を出して、ログに記録する場合 2.1 reverse proxyで記録する場合 2.2 app serverでログに記録する場合 1と2とでは出てくる数字が違うだろうけど、本件に必要なのはパフォーマンス改善を示す一貫した指標なので、どっちでもいいと思う。 1. reverse proxy側で取る場合 1.1 nginx log_formatディレクティブに$upstream_response_timeという変数
複数のWebサーバでSSLセッションキャッシュを共有してSSL処理を高速化(Apache + mod_ssl + mod_socache_memcache) - 元RX-7乗りの適当な日々
HTTPS(SSL利用)サイトがSEO的に優遇されるトレンドで、世間的にもHTTPS接続でサイト運用するサービスが増えてきています。 これが、ハイトラフィックサイトになってくると、このフロントエンドでSSL処理させることが負荷的にもなかなか辛いのです。 で、Apache 2.3以降では、Shared Object Cache Providerとして、memcachedが選択できるようになっています。 この仕組みを利用して、Apacheとmemcachedを並べることで、各サーバでユーザのSSL Session Cacheを共有しながらHTTPSリクエストを負荷分散できる構成を作ってみました。 WebサーバでSSLオフロード 常時SSLを利用したWebサイトを運用するために、SSLアクセラレータといったアプライアンス製品だとか、ソフトウェアだとApacheやNginxのSSLモジュールを使う
NginxでリバースプロキシをKeepAliveしたときの性能検証 - Qiita
Nginx + Luaを用いた、ハイパフォーマンスで動的なプロキシサーバを考察中です。 そのための施策の一つとして 上流サーバへのアクセスをKeepAliveする という方法がありますが その際、プロキシサーバにどの程度性能に変化があるのかを調査してみました。 リバースプロキシのkeepalive設定 前提条件として Nginx > 1.1.4 が必要。 upstreamに keepalive というattributeがあるのでそれを設定します。 それと同時に、プロキシヘッダーにHTTP/1.1設定などを行いましょう。 ちなみにproxy_passだけだとkeepaliveできないようです。upstream必須。 あと、もちろんバックエンドサーバ側もkeepalive設定しておきます。 upstream http_backend { server oreore.micro.service;
ざっくりと #isucon 2013年予選問題の解き方教えます : ISUCON公式Blog
こんにちは、@acidlemon です。 ざっくりと書いたつもりなのに長編です。 本エントリでは、スコアがなかなか伸びなかった方々を主な対象として、実際に先週末実施した予選問題を解いていく方法を解説します。高スコアをたたき出した方々は参考までに「こんなやりかたでもここまでスコア伸びるんだなー」という感じで読んでください。 最初の方針は「派手なことをしない」「コンサバにやる」です。「とりあえず」という気持ちでmemcachedやRedis、もしくはvarnishやnginxでキャッシュし始めるとキャッシュの寿命のことを考え始めなければならず、疑心暗鬼になったりして難易度が上がります。まぁその辺は最終的には男気によって解決するものなのですが、その要素を排除したままできるだけスコアを上げてみましょう。 日曜夜よりアップされたみなさんの感想エントリなども拝見しており、やっぱオンメモリに置くのは速い
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
NGINX Documentation
httpsだからというだけで安全？調べたら怖くなってきたSSLの話!？ - Qiita
たいぷらいたーざっき。(2012-03-18)
実践nginx〜メルカリの場合〜
HTTP/1.1 -> SPDY/3.1 -> HTTP/2
