Nginxを使ったもう一歩進んだWordPressチューニング
Nginxを使ったWordPressのチューニングといえば、フロントエンドのNginxとバックエンドのNginx（もしくはApache）に分けてproxy cacheを効かせるのが王道です。 さらにWP Super Cacheプラグインを利用してなるべくPHPやMySQLにアクセスさせないようにすると、手軽で絶大なパフォーマンスアップが可能です。 今回はそこからもう一歩進めたチューニングについて書きたいと思います。 二段階層を廃したシンプルな構成 まずは、図をご覧ください。 前述の王道チューニングの構成はA図となります。 proxy cacheはNginxがバックエンドのサーバーに処理を回し、返ってきたレスポンスをキャッシュして、Nginx自身がキャッシュを返すことでパフォーマンスを上げる仕組みです。 A図-1がキャッシュの無いアクセス、A図-2がキャッシュが効いているアクセスを表していま
Tuning Nginx for Best Performance
This article is part 2 of a series about building a high-performance web cluster powerful enough to handle 3 million requests per second. For this part of the project, you can use any web server you like. I decided to use Nginx, because it’s lightweight, reliable, and fast. Generally, a properly tuned Nginx server on Linux can handle 500,000 – 600,000 requests per second. My Nginx servers consiste
Nginx Tuning For Best Performance - Codestance
For this configuration you can use web server you like, i decided, because i work mostly with it to use nginx. Generally, properly configured nginx can handle up to 400,000 to 500,000 requests per second (clustered), most what i saw is 50,000 to 80,000 (non-clustered) requests per second and 30% CPU load, course, this was 2xIntel Xeon with HT enabled, but it can work without problem on slower mach
nginxのupstreamから502を対象外にする | SawanoBlog 2G
railsをunicornでrackupする際、よくunixsocket経由でnginxをフロントに使う。 で、それをバックエンドにしてさらにNginxでロードシェアする時の設定。 バックエンドのunicornが健在の時はフロントバック間のレスポンスは上図のようになり、適当にロードシェアされます。 nginxのデフォルト設定ではバックエンドがunicornの状態に応じて502を返す際にも、フロントは気にしません。 上図の状態になってもupstream対象を調整せずに、200, 502, 200, 502 とレスポンスを返します。 そりゃ困るということでドキュメントを参照、 HttpProxyModuleのproxy_next_upstream を使ってupstreamのポリシーを指定すればOKです。 デフォルトだとこうなっているので、 “proxy_next_upstream e
nginx ドキュメント訳: nginx はどのようにリクエストを処理するか |
nginx（Wikipediaの説明）のドキュメントの訳を始めました。ライセンスが不明なのですがオープン系と仮定してとりあえずここで公開し、ある程度量がまとまったら nginx の中の方に連絡をとって nginx サイトに入れてもらいたいと考えてます。 あと、nginx のドキュメントは wiki もありますが、表側はだいぶん訳されているようなのでこのドキュメントをまず訳してから、wikiを訳していこうと思います。 で、今回は「Introduction to nginx（nginx 入門）」の「How nginx processes a request（nginx はリクエストをどのように処理するか）」を訳しました。 *** nginx はどのようにリクエストを処理するか 原文: How nginx processes a request ネームベースの仮想サーバ サーバー名未定義のリク
Direct Data Transfer: NginxのX-Accel-Redirectを使って直接データを転送する — LS4 v1.0.0 documentation
目的¶ LS4の用途の一つにWebサービスの画像ストレージシステムがあります。このようなWebサイトでは、アプリケーションサーバの前面にHTTPリバースプロキシを設置しているでしょう。 もしHTTPリバースプロキシとして nginx を使っているなら、nginxの “X-Accel-Redirect” 機能を組み合わせる事で、アプリケーションサーバのCPU負荷とトラフィックを削減することができます。 このドキュメントでは、次のようなWebバックエンドシステムを想定しています： Internet | load balancer / reverse proxy (1) / (5) / App (3) (2) | ----------- GW / | +-------------+ (4)| | | | | | +-|--+ +----+ +----+ | MDS | | DS | | DS |
[apache][nginx]apacheとnginxでX-Reproxyを使う Feedbox
lighttpd でも使えるらしいんですが、個人的に使ってないので割愛 http://www.google.co.jp/search?gcx=w&sourceid=chrome&ie=UTF-8&q=lighttpd+x-reproxy X-Reproxy-URLはPerlbal + MogileFSなどでファイル配信する場合によく使う、とは聞いていたのですが、X-Reproxyヘッダを解釈できるのはperlbalだけだと思ってました。 でちょろっとぐぐったら既に他のhttpdでも対応しているようで。 apache kazuho 先生がお作りになったmod_reproxyモジュールを使う。 http://developer.cybozu.co.jp/kazuho/2009/10/apache-x-reprox.html nginx http://d.hatena.n
nginx は 複数の URL が含まれた X-REPROXY-URL ヘッダを扱えない - @kyanny's blog
Perlbal には、リバースプロキシとして利用しているときバックエンドが X-REPROXY-URL というヘッダに「ファイルの実体の URL」を入れてレスポンスを返すと Perlbal が改めてその URL にリクエストして (reproxy) 実体をとってきてからクライアントに返す、という機能があり、画像や動画などファイルサイズが大きい静的コンテンツを配信するのに便利なのでよく使われている。特に MogileFS と組み合わせて使う例がよくみられる。 この X-REPROXY-URL ヘッダによる reproxy 機能は Perlbal 以外のウェブサーバでもサポートされていて、 nginx でも扱うことができる (Apache や Lighttpd でも対応したモジュールがある) できるんだけどリバースプロキシを Perlbal から nginx に変更したら X-REPROXY-
nginxでMogileFS - スコトプリゴニエフスク通信
このトピックが役に立った。PerlbalのX_REPROXY_URL的なことをnginxでやるnginxがリバースプロキシになっていて、背後(127.0.0.1:8000)にアプリケーションがいる場合、次のような設定になる。 upstream django { server 127.0.0.1:8000; } server { listen 80; server_name localhost; location / { proxy_pass http://django; } location /reproxy { internal; set $reproxy $upstream_http_x_reproxy_url; proxy_pass $reproxy; proxy_hide_header Content-Type; } } はまったのが、"proxy_pass $reproxy"のよ
入門！ nginx - tumblr
最近話題のnginxについに手を出したのですが、「nginx入門」みたいなブログ記事も一切見当たらず、あるのは英語のドキュメント記事くらい…という状況だったので、自分なりに訳して理解した部分を忘れないよう覚書。 今node.jsもちょこちょこやっているのですが、これまた物凄い勢いで開発が進む上に、その情報のほとんどは英語なわけでやはりもうホントに英語が読めないとどうしようもないんだなぁと実感しているわけです。まぁstackoverflowとか見ててもそこまで難しい文法使ってるわけでもないので、英語を見た瞬間に拒否反応起こしたりしなきゃなんとかなりそうですが。 「毎度毎度ブログ長すぎ死ね」とはてブのコメントで話題の僕のブログ、今日も長いです。 nginxってそもそもどう読むんだよ 「エンジンエックス」と読みます。正直すごくかっこいいです。apacheとかtomcatとかnginxとか、サーバ
#isucon ではどんなことを考えながら作業していたか - 酒日記 はてな支店
前のエントリ #isucon で優勝してきました は当日夜に酔っ払った頭で勢いで書き上げたので、少し冷静に振り返ってまとめてみます。 最初のボトルネック発見 DB が CPU 4コアをフルに使って回っているのですぐに Query が重いのは分かった 重いクエリはキャッシュすれば、という発想は自然 (実際 MySQL のクエリキャッシュだけでスコアは 1.5倍程度上がる)、とはいえ このクエリは実行に 300〜400 ms 程度かかる アプリケーションの要件上、毎秒更新する必要がある 1秒ごとに更新に 0.3〜0.4秒かかる処理をするのは悪手だろう cache が消えてから生成、とすると生成処理が複数同時に走って無駄が大きい (実際ベンチマーク中の slow query を見ると 600〜700 ms 程度の時間が掛かっていた) ということで、DB のテーブル構成を変更して高速化できないか、
nginxから始めるWebサーバー構築入門 [1] - オブログ
こんにちは、hsbtです。 北海道から関東に引っ越してきて、そろそろ体験したことのない暑さの季節だなあと毎日おびえている毎日です。 さて、今号から近年注目されている Web サーバーの nginx を用いて、Webアプリケーションを運用していく上でのノウハウを連載として紹介していきたいと思います。 nginx はロシアのIgor Sysoev 氏によって 2004 年にリリースされた、高性能かつオープンソースのHTTPサーバーです。公式サイトによれば現在では世界中のドメインの6.55%のサイトが nginx によって動作しています。 nginx は HTTP サーバーとしてだけではなく、以下のような特徴を持っています。 リバースプロキシ IMAP/POP3プロキシサーバー シンプルな設定ファイル 少ないリソース消費量 特に少ないメモリ消費量とHTTPサーバーとしての高い性能から、リソースに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
