$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" "
こんにちは。 インフラチームの野島（@nojima）です。 チームのメンバーに nginx の設定について気をつけるべき点を共有するために、レビュー観点を書きました。 せっかくなのでここで公開します。 ほとんどの項目は自分やチームのメンバーの実体験に基いています。 レビュー観点 server server_name が他のやつと被っていないか。 listen する IP アドレスが同じ場合、server_name で区別できないといけない。 TLS を使う場合、SNI をサポートしないクライアントでは TLS 用の設定が default_server のものが使われる点にも注意。 TLS を使う場合、listen ディレクティブに ssl オプションを書いているか。 location location のマッチの順番に注意 正規表現の location は前方一致の location より
解説 worker_processes auto; - Nginx本体のプロセス数、autoにしてnginx内部判定に任せるのは賢明 worker_rlimit_nofile 100000; - workerプロセスが最大に開けるファイル数の制限。このように設定したら、ulimit -a以上のファイル数を処理できるようになり、too many open files問題を回避できる worker_connections 2048; - 一つのworkerプロセグが開ける最大コネクション数 multi_accept on; - できるだけクライアントからのリクエストを受け取る use epoll; - Linuxカーネル2.6以上の場合はepoll、BSDの場合kqueue server_tokens off; - セキュリティ対策です、エラー画面のnginxバージョン番号を非表示 sendf
以前開発のドキュメントをどこに置くか問題 - $shibayu36->blog;という記事を書いた。まだよい方法はちゃんと考えられてないが、少しずつケースバイケースでいろいろな手法を試してみている。今回は設定項目の仕様のドキュメントという観点で考えたときに、テストを作ることで解決できないか、ということについて書く。 設定項目の仕様 例えば以下の様な設定があったとする*1。 [ { "blog_url" : "http://shibayu36.hatenablog.com/", "permission" : "public", "can_be_edited_by" : [ "shiba_yu36" ] }, { "blog_url" : "http://shibayu36-private.hatenablog.com/", "permission" : "private", "can_be_
アプリケーションでどうしても捌けない量のリクエストが一時的に押し寄せてしまう場合、アプリケーションサーバが死ぬのを避けるために GET は制限を掛けたいが、POST はリトライが面倒なのでなるべく通してあげたい、というような要求を nginx で処理できるかどうか。 実装として一番望ましいのは GET は 100 req/sec で制限 (超えたら503) POST は無制限 のようにメソッドごとに別々の制限を掛けることだったのですが、とりあえず HttpLimitReqModule を使うことで、メソッドごとに同一の上限を設定することはできました。 http { limit_req_zone $request_method zone=method:1m rate=100r/s; server { listen 80; location / { limit_req zone=method;
Webサイトでいろいろなサイズの画像を使いたいとき、URLのパラメータを変えるだけでサイズ変換してくれると非常に便利です。クックパッドのTOFUとかわりと有名ですね。開発効率も上がるし、面白そうだったのでNginxで実装してみました。 TOFU : 料理を楽しくする画像配信システム フルサイズの画像 元の画像です http://pic.kksg.net/shirakawago.png 比率固定リサイズの画像 /scale/128x128 を挟むと縦横の最少が128pxの画像になります。 http://pic.kksg.net/scale/128x128.shirakawago.png サイズ指定切り抜き c オプションで切り抜き。指定サイズいっぱいに、いい感じに切り抜きます。 http://pic.kksg.net/scale/c.600x150.shirakawago.png グリッチ
A modern HTTP server running on somewhat recent hardware is capable of servicing a huge number of requests with very low latency. Here’s a plot showing requests per second vs. number of concurrent connections for the default index.html page included with nginx 1.0.14. With this particular hardware & software combination the server quickly reaches over 500,000 requests/sec and sustains that with gr
nginxと言えば、言わずと知れた高速なwebサーバ+ロードバランサです。 とにかく軽量で高速なので、apacheをこれに置き換えて高速化という話もよく聞くようになって来ました。 先日、このnginxとmemcacheを組み合わせてセッション認証サーバを構築したので、それについて書こうと思います。 今回作るシステムは、静的コンテンツを配信するサーバがすでにあり、 ・認証機構（ログイン画面）を追加 ・変更を最小限に抑えて開発 ・スケールアウトしやすい ・アクセス数が多いので、できるだけ処理を軽くする ことを目的とします。 この手のシステムは、既存システムに手を入れるのが普通ですが、既存システムでプログラムが動かないことには話になりません。 という事で、認証機構を追加したプロキシサーバを作成することで実現したいと思います。 仮に、PHPのみを使用して実装する場合は、下記のように出来ます。 ・ロ
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という変数
画像配信など大量にアクセスを捌く際にちょっと気になっていたhttpなupstreamとkeepaliveできない件が、nginx-1.1系でできるようになったので試してみた 今回keepaliveできるようになったのは↑のbackendと通信するところ。 本家のドキュメントはこちら http://nginx.org/en/docs/http/ngxhttpupstream_module.html#keepalive keepalive機能を使うには、以下のように設定します http { upstream backend { server 127.0.0.1:5000; keepalive 16; } server { listen 8080; server_name localhost; location / { proxy_http_version 1.1; proxy_set_head
Nginxは非常に強力なhttpdですが、独自のモジュールを実装しようとするとこれまた非常に敷居が高い印象です。 追記 この記事よりも前に http://openresty.org/#DynamicRoutingBasedOnRedis でほとんど同じ内容のエントリが書かれていました。こちらも参照ください モジュールの開発はむずかしい まず開発用のドキュメントはほとんどありません。必然 既存のモジュールをお手本としますが、コメントも少ないのでソースだけが頼りです。 {ファイル,ネットワーク} I/O を伴う処理では、Nginxのノンブロッキング/イベントドリブンのアーキテクチャにのっとってコールバックを駆使したCで実装する必要があり、LLで育ったゆとり脳では太刀打ちできませんでした lua-nginx-module が代わりになるかも なんらかのNginxモジュールを開発しなければならない
ざっくり概要 ピークで3000req / sec 毎分コンテンツ更新要求 コンテンツ更新の際は他所からデータをapi経由で受け取る コンテンツ更新にはTheSchwartzを使用 なコンテンツを色々してきたログ。 尚、ここに書く技術は大半が周囲のギークな方々にサポートしてもらったもので、僕自身が何かしたわけではない。残念すぎる。 構成 internet -> www(squid -> apache) -> app(memcached -> app) -> db フロントエンド wwwサーバがapacheとsquidを動かしている。apacheがリクエストを受け、squidのキャッシュが有ればそれを返し、無ければバックエンドのappサーバへproxy。 バックエンド appサーバがmemcachedとアプリを動かしている。 それぞれ冗長化してるけど、リクエスト数の割に台数は少ない。 技術があ
Traditional ESI ESI is a technology used by many proxy cache tools like Squid and Varnish to define dynamic requests on the server side. This allows you to serve a static or cached version of a page with only certain elements needing to be generated by the server-side. Like many application developers I'm cheap and lazy, I don't really have the resources to run a separate frontend cache before req
完全に文化祭疲れで昼寝3時間ぐらいしてしまいましたが、懇親会で聞かせて頂いた話やblogやtwitterをみる限り好評だったようで、うれしく思っています。ISUCONに参加して頂いた方、社内で協力して頂いた方ありがとうございました いくつか至らぬ点がありますが、明日以降に公式にフォローさせて頂きたいと思っています。 さて、既に公開されているので見た方は多いと思いますが、今回ISUCONで使ったベンチマークツールは大きく分けて次の3つのツールに分かれています。 (1) 1post/secでコメントを投稿し、1秒後にコメントをしたページと、インデックスおよび適当な記事のDOMチェックを行う node.js (2) http_load + patch (3) css/js/imageのMD5値を検証する perl script 最終的な順位はhttp_loadが行ったリクエスト数で決まるのでもし
ISUCONに行ってきました。社内での事前βテストに参加して問題を知っていたので出場はせず。社内β参加を持ちかけられたときは、正直「めんどくせーなｗ」が素直な感想だったんですが、実際にやってみるとスコアがリアルタイムにわかる＆ちょっとずつ自分のスコアが上がっていくってのは楽しくて、わりと本気でチューニングしてしまいました。 さて、本戦でも14時頃からお遊び用としてサーバー一式が解放されたので、大人げも無くそこで112500req/minをたたき出して参加者のやる気を削いだ（・・と懇親会で言われました。色々すいません！）構成について。 reverse proxy nginx(1.0.5) ngx_http_memcached + ngx_http_ssi_filter + ngx_http_scgi + ngx_http_upstream_keepalive(3rd party plugin
はじめに nginxは頻繁に保守されていてどんどんバージョンが上がっていく一方で、UbuntuやWindows以外ではソースコードからビルドする方法が一般的だと思います。 nginxのバージョンアップ頻度 2011/05/10 1.0.2 2011/05/03 1.0.1 2011/04/12 1.0.0 2011/04/04 0.9.7 2011/03/21 0.9.6 nginx CHANGESより LinuxやBSDの多くのディストリビューションではNginxがパッケージリポジトリに含まれており、通常のソフトウェアインストール手法でインストールする事ができます。(Debianにおけるapt-getや、Gentooにおけるemerge、FreeBSDにおけるports、Fedora の yum、Vine Linux の apt-get など） たまにこれらのパッケージは古いものであった
※この記事はnginxの現時点での最新stable 0.8.54を使っています。 2回目の投稿になります、sugyanです こんにちは。 最近、jsdo.itでちょっとしたAPIを作ってみているのですが、連続で大量のリクエストが来るのはちょっと困るので、防御策としてnginxのリクエスト制御モジュール"HttpLimitReqModule"を導入してみることにしました。 http://wiki.nginx.org/HttpLimitReqModule 何も設定しない場合 まずは普通のnginx設定でhttpサーバを立ち上げて、動かしてみます。 worker_processes 1; error_log logs/error.log info; events { worker_connections 256; } http { log_format test '$remote_addr -
EC2 だと ELB の内側では、nginx のアクセスログに ELB の IP アドレスが記載されてしまうので、HttpRealIpModule を使って Apache の mod_rpaf、lighttpd の mod_extforward と同じような挙動を設定します。 configure オプションに --with-http_realip_moduleが必要ですので、nginx -V で configure オプションを確認して、入っていなかったらコンパイルし直しましょう。 実際の設定は以下です。set_real_ip_from に ELB など Proxy やロードバランサーの IP を指定します。real_ip_header には、X-Real-IP や X-FORWARDED-FOR など Proxy が追加するヘッダーを指定してください。 http { set_real_i
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く