Smart and Efficient Byte-Range Caching with NGINX & NGINX Plus When correctly deployed, caching is one of the quickest ways to accelerate web content. Not only does caching place content closer to the end user (thus reducing latency), it also reduces the number of requests to the upstream origin server, resulting in greater capacity and lower bandwidth costs. The availability of globally distribut
はじめに NGINXが接続処理に非同期かつイベント駆動のアプローチを用いていることは、よく知られています。つまり（従来型アーキテクチャのサーバのように）、専用プロセスやリクエストごとのスレッドを他に作ることなく、一つのワーカープロセスで複数の接続とリクエストを処理できるということです。これを実現するために、NGINXはソケットをノンブロッキングモードで実行し、epollやkqueueといった効率的なメソッドを用いています。 全負荷のかかるプロセスは少なく（通常1CPUコアごとに1つのみ）一定のため、消費されるメモリは少なく済み、タスク切り替えのためにCPUサイクルが無駄遣いされることもありません。このアプローチのメリットは、NGINXの実例を通してよく知られています。NGINXは、何百万もの同時リクエストやスケールを非常にうまく処理します。 各プロセスが追加メモリを消費する。また、プロセス
OpenRestyはnginxのほかにngx_luaをはじめとするCで書かれた各種サードパーティモジュールとngx_luaのAPIを利用したrestyモジュール、そしてLua/LuaJITで構成されています。 OpenRestyに含まれているnginx自体は本家のnginxと基本同じなので、別にOpenRestyを利用しなくても自分でngx_luaを組み込んだり、サーバ上にrestyモジュールを配布することで似たような環境を構築することは可能ですが、OpenRestyであれば主要なモジュールやライブラリが./configure、make、make installの一連の流れですべてゴソッとインストールされますし、OpenRestyのconfigureスクリプトはnginxのconfigureスクリプトを継承したものなのでnginxのconfigureオプションをほぼそのまま利用することもで
Some Background Recently, we submitted fadeit.dk to AWWWARDS - the awards for design, creativity and innovation on the Internet. It gave us a nice little boost of website visitors. However, not all of that attention was positive… Referer Spam Bots While the majority of our traffic came from genuine sources, we started noticing a pattern in our referral traffic. What’s up with social-buttons.com? W
Docker で開発環境を作る話 こんにちは、Docker 0.9 が出ましたね。 ちょっと Docker を触っていて幾つかアレな点があったので共有しておこうと思います。 その他も合わせてまとめてます。 私の Docker TIPS Docker を使って開発環境、および開発環境の土台を作る まあよくある Docker の使い方って nginx だの redis だのいろんなサーバーを構築する感じだと思いますが。 今回は開発環境を構築する話をしたいと思います。 よく dotfiles なんかを github においてーなんてことやってる方多いと思います。 もうここは思い切って Docker のイメージにしてしまいましょう。 利点 モテる なんかイケてる感じがする 案件、プロジェクト毎に個別環境をクリーンなまま維持できる みんな同じ環境で作業することができる（ライブラリのバージョンなどが揃
Valentin V. Bartenev vbart at nginx.com Mon Jan 27 20:02:19 UTC 2014 Previous message: : [PATCH 0 of 1] Mail: add support for SSL client certificate Next message: [PATCH] SPDY/3.1 protocol implementation Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] http://nginx.org/patches/patch.spdy-v31.txt This patch upgrades implementation of SPDY protocol in the ngx_http_spdy_module from draf
背景 自前のサービスでhttps通信をサポートするには、SSL証明書が必要になります。 自分で使用するだけなら、SSL証明書も自前で作成するいわゆるオレオレ証明書を用いても良いのですが、外部に公開するサービスの場合そうとも行きません。 SSL証明書というと値段が高い印象がありましたが、StartSSLというサービスで無料でSSL証明書の発行を受けられると言うことで試してみました。 StartSSLにユーザー登録する 証明書の発行を行う前に、StartSSLにユーザー登録する必要があります。 StartSSLから、"StartSSL Free (Class1)"を選択します。 Certificate Control Panelを選択。 Sign-upに進みます。 名前、住所、メールアドレスなど 個人情報の登録を行います。 登録したメールアドレスに本人確認のメールが届くので、受信したメールのa
前回と前々回の続き。 今回はvarnishの設定。 各設定の補足はコメントにて記載。 *設定 # # backend # backend app { .host = "app.hogehoge.com; .port = "80"; } # # acl purge setting # acl purge { "localhost"; "127.0.0.1"; } sub vcl_recv { set req.grace = 300s; ## 不正なmethodは拒否 if (req.request != "GET" && req.request != "HEAD" && req.request != "POST" && req.request != "PURGE" && req.request != "BAN") { error 403; } ## purgeの設定 if (req.requ
最近nginxを調べてたのはこれがやりたかったからです。 長くなりそうだから複数に分けます。 環境 OS CentOS6.4 lb nginx1.4.1 cache varnish3.0.3 web(静的) nginx1.4.1 web(動的) apache2.2.15+php5.3.3 構成 Internet ------------------------------- | | | ------------------- | | lb + cache | | ------------------- | | | ------------- ------------- | web(動的) | | web(静的) | ------------- ------------- | ------------- | db | ------------- lb nginxが担当します。 cache v
前回の続き。 というわけで設定を晒してみる。 今回はLBのnginxの設定。 基本設定 nginx.confの設定 worker_processes 1; error_log /var/log/nginx/error.log warn; pid /var/run/nginx.pid; events { worker_connections 1024; } http { include /etc/nginx/mime.types; default_type application/octet-stream; server_tokens off; log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_u
（※）このページで紹介している事項は記事初出時点の情報に基づいたものです。本ページはアーカイブとして掲載しています。 ツイート 2012年6月26日 前回、前々回は、キャッシュサーバに期待される役割と、キャッシュサーバやキャッシュエンジン、特にVarnish Cache、Apache Traffic Serverについて、IIJで行った比較実験の結果を交えて詳しく説明しました。最後に、nginxについて取り上げます。 nginx nginxは、既に紹介している機能のほかに、下記のような特徴を持っています。 非同期のイベント駆動による高速な処理能力 サービスを止めずにバイナリをアップデートできる 豊富な3rdパーティ製モジュール nginxは、既に紹介している他のキャッシュエンジンと同様に、接続を非同期のイベント駆動の仕組みで処理しますが、処理能力はその中でも高く、多くの接続が集中するサイト
Varnish Cache Varnish Cacheは、前回述べたVCLという設定ファイルの記述方法において、下記のような特徴があります。 設定ファイルの動的読み込み インラインCによる設定 Varnish Modules（VMODs）による拡張 probeによるオリジンサーバのヘルスチェック まず、Varnish CacheではVCLで記述された設定ファイルをC言語として解釈します。設定をC言語として解釈した後に設定ファイルをコンパイルし、共有ライブラリを作成します。最終的には、Varnish Cacheが設定ファイルから生成された共有ライブラリをリンクすることで、設定が反映されます。このような実装により、Varnish Cacheではプログラムを作成する感覚で、柔軟性に富んだ設定ファイルを作成できます。また、コンパイルした結果をリンクさせているため、全体的に速度向上を期待できるという
ツチノコブログのWEBサーバベンチマークツール比較の記事で紹介されていた。WebサーバのG-WAN。この記事によると凄く速いようです。 Intel Xeon E5-2640 (6コア/12スレッド 2.50GHz) を2つというサーバで gwan 334944 req/s nginx 111842 req/s と、速いと言われているnginxの3倍の速度を出しています。 このベンチマーク結果がとても気になったので、なぜG-WANが速いのか、自分でも検証してみました。 結論から言うと以下の2つ。 1) G-WANはデフォルトで物理CPUに合わせた数のスレッドを起動する 2) HTMLファイルも一度読み込んでキャッシュする という事です。 今回はAWSのcc2.8xlarge(E5-2670 8コア/16スレッド 2.60GHz *2)を使ってベンチマークを行いました。OSはAmazon L
今更ながら、nginxにmapという機能があることを知った。 → HttpMapModule ということで、以下のことを試してみた。serverブロックの外側に以下のような記述を追加してみる（中に書くと怒られる）。 map $http_user_agent $myindex { default /index.html; ~(iPhone|Android) /index_sp.html; } んで、serverブロックの中のlocationの指定で location / { root /path/to/document/root; index $myindex; } って感じでindexの値をmapで指定した値に変えておくと、UserAgentに「iPhone」とか「Android」って入ってればindex_sp.htmlをインデックスファイルに、そうでなければindex.htmlをインデッ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
