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でngx_http_upstream_hash_moduleを有効にする - うまいぼうぶろぐ
ngx_http_upstream_hash_module upstreamディレクティブでbackendのサーバに振り分ける際に、特定の変数(のハッシュ値)パーシステンスできるモジュール。デフォルトではremote addr(ソースIP)でパーシステンスするip_hashがある。 http://wiki.nginx.org/NginxHttpUpstreamRequestHashModule 使用できる変数はここ。 http://wiki.nginx.org/NginxHttpCoreModule#Variables パーシステンス デフォルトのip_hashの設定 upstream backend { ip_hash; server 192.168.0.1; server 192.168.1.1; } ngx_http_upstream_hash_module リクエストURIで振り分
nginx 1.0.0 が出てます - dogmap.jp
高速、軽量な HTTP サーバ(かつリバースプロキシサーバ) nginx が開発開始から9年を経て、ようやくメジャーリリース 1.0.0 公開されました。 W3Tecs によれば、Apache, IIS についで第3位の6.8%のシェアを誇るまでになったそうです。 このサイトと私がやってるフォトブログ shot.dogmap.jp も、リバースプロキシサーバとして nginx を使用しています。 nginx の導入方法として過去にも何回かエントリ書いてますので、そちらも読んでやってください。 WordPress サイトに nginx を導入する Amazon Linux AMI に nginx 最新版をインストール さて nginx を CentOS 等で利用する場合、yum のリポジトリに epel を加えることで yum install nginx でインストールできるのですが、残念な
Nginx に cache purge モジュールを追加する - dogmap.jp
Nginx をリバースプロキシとして使用する場合、キャッシュされたページを削除したくなることがあります。 しかし、素の Nginx ではキャッシュを削除するには、キャッシュディレクトリ配下の全ファイルをすべて削除するしか方法はありません。 （もしくは、設定時間が経過して自動削除されるのを待つか） ページ単位で Nginx リバースプロキシのキャッシュを削除するには、ngx_cache_purge というモジュールを追加することで実現できます。 この ngx_cache_purge モジュールを組み込んだ rpm パッケージを作成する方法を説明します。 rpm パッケージの作成方法については、以前書いたエントリ「nginx 1.0.0 が出てます」を参考にしてください。 このエントリでは、ここまでの作業が終わっているものとして解説します。 Nginx に ngx_cache_purge モジ
Nginxを使ったもう一歩進んだWordPressチューニング
Nginxを使ったWordPressのチューニングといえば、フロントエンドのNginxとバックエンドのNginx（もしくはApache）に分けてproxy cacheを効かせるのが王道です。 さらにWP Super Cacheプラグインを利用してなるべくPHPやMySQLにアクセスさせないようにすると、手軽で絶大なパフォーマンスアップが可能です。 今回はそこからもう一歩進めたチューニングについて書きたいと思います。 二段階層を廃したシンプルな構成 まずは、図をご覧ください。 前述の王道チューニングの構成はA図となります。 proxy cacheはNginxがバックエンドのサーバーに処理を回し、返ってきたレスポンスをキャッシュして、Nginx自身がキャッシュを返すことでパフォーマンスを上げる仕組みです。 A図-1がキャッシュの無いアクセス、A図-2がキャッシュが効いているアクセスを表していま
nginxでX-Accel-Redirectを使う場合に余計なヘッダを削除する - 酒日記 はてな支店
アプリケーションで認証後 S3 のコンテンツを返したかったのだけど、nginx で BASIC 認証を掛けていたらうまくいかなかった、というお話。 Amazon S3 の認証トークン付き URL をアプリケーションで生成し X-Accel-Redirect ヘッダに出力 nginx が S3 から取得してきてクライアントに返す という動作をさせたくて、以下のように設定。 # nginx.conf location = /reproxy { internal; set $reproxy $upstream_http_x_reproxy_url; proxy_pass $reproxy; proxy_hide_header Content-Type; }アプリケーションからは以下のようなレスポンスヘッダを出力。 X-Accel-Redirect: /reproxy X-Reproxy-URL:
Webサーバ勉強会#4に行ってきた＆しゃべってきた #study2study - たごもりすメモ
参加者全員が何かしらしゃべるという大変にハードコアな勉強会「Webサーバ勉強会」*1に行ってきた＆しゃべってきた。今回のお題は nginx で、あちこちで名前は聞くけどそこまでみんな使ったことがあるわけでもないという微妙な普及具合にうまく目をつけてる。 Webサーバ勉強会 #4 : ATND 主催の @oranie さん、および参加者のみなさま、お疲れさまでした！ で、自分がしゃべった内容は以下のスライドの通り。 livedoor blogのsorryサーバの話 #study2study View more presentations from tagomoris 9/14にあったlivedoor blogメンテナンス専用のsorryサーバの話だけど、性能面のグラフとかぜんぜん記録とってなかったので実績分についてはだいぶあいまい。当日も朝方は意識が朦朧としてたし。設定ファイルその他はぜんぶ
Webサーバ勉強会 #4 | Carpe Diem
Webサーバ勉強会 #4 で、Nginx のコンフィグレーション 1 行目から 24 行目までの説明を話してきました。その他にも当日キャンセルになった fastcgi_conf と mime_types もかなり手抜きですが、取り急ぎまとめて slideshare へアップしておきました。 Nginx は、今まで本番環境では使ったことがないので、かなり設定ファイルが分かりやすいし、かなりの実戦投入している話を聞けたので、とても勉強になりました。 Webサーバ勉強会は、参加者すべて発表しないといけないため、参加人数は少ないですが、発表している中でも、みんなでわいわいとそれぞれの情報を出しあって、わいわいと勉強できるとても緩い勉強会だと思うので、皆さんも機会がありましたら参加してみてください。
nginx で lighttpd のようにユーザーをトラッキングする方法 - unknownplace.org
lighttpd では mod_fastcgi や mod_proxy 経由でアプリケーションが、 X-Lighttpd-Hogehoge: foobar のような X-Lighttpd- ではじまるヘッダーを返してもそれをクライアントに送り返さないという仕組みがあり、 たとえばそれを利用してアプリからユーザーIDを返してあげたりすると、それをクライアントに送ることなく lighttpd のアクセスログにだけ記録する、といったようなことが出来て便利なのですが、 同じようなことを nginx でやりたかったのでしらべてみた。 アプリから X-MyApp-User: foobar みたいなのを返してそれをクライアントに送ることなくアクセスログに記録したい場合、まずクライアントに送らないように、 proxy_hide_header X-MyApp-User; とし、さらに accesslog の
痒いところに手が届かないnginxのHttpLimitReqModuleさん
軽くて早いと巷で評判のリバースプロキシサーバnginxですが、 標準で連続リクエストを制御する機能がついているのもまた魅力の一つです。 nginxのHttpLimitReqModuleを試してみる | tech.kayac.com - KAYAC engineers' blog こちらで詳しく紹介されているHttpLimitReqModuleを利用することで、任意のURLに対して1秒あたり/1分あたりに何リクエストまでしか処理しません、という制御が設定ひとつで出来てしまいます。例えば公開しているAPIのURLがあって、もちろん使って欲しいのだけどDOS攻撃みたいなのは困るわ...みたいな時に安心です。なお、リクエストが溢れた場合に速攻で503レスポンスを返すのか、ある程度は「処理待ち」としてキューに貯めるのか（burst対策）というのも設定一つです。ここまでの機能をアプリケーション側で実装
さくらVPSとnginxリバースプロクシで最速WordPressブログを作る方法（ベンチマーク付き）
負荷的に厳しくなってきたので sakuratan.biz を Apache（さくらスタンダード）から nginx（さくら VPS 512）に移転しました。 頻発していた 503 もほとんど出なくなって快適です。 Apache から VPS の nginx へ WordPress を移転したいと考えている人もいるかなーと思いましたので、さくら VPS で nginx リバースプロクシを使った WordPress ブログの構築する方法をがっつり書いていきたいと思います。 結構長文になってしまいましたので、先に索引を載せときます。 nginx とは nginx が速い理由 リバースプロクシ さくら VPS にインストールするシステム構成 EPEL パッケージリポジトリのインストール MySQL のインストール PHP のインストール nginx のインストール nginx と PHP FastC
#isucon で学ぶWebアプリの高速化の話 : As Sloth As Possible
あるいは、お遊びチーム2号は一体何をしていたのかについて。 ISUCONという大変白熱した楽しいお祭を開催するにあたって、その前夜祭的な環境試験のためのチューニング祭が社内の有志数名で行われていて、そのときに色々学んだことをおまけとして書いておきます。 ISUCONて何？ 下記参照。 なんでもありのWebアプリケーション高速化バトル、#isucon 開催のお知らせ 【締め切りました】Webアプリケーション高速化バトル、#isucon 詳細と参加者募集開始 ISUCON に参加してきました #isucon に参加してきました＆isuconツールを試してみました #isucon で優勝してきました isuconに参加してきた＆チーム「いんふらえんじにあー」の戦略など isuconお遊びチーム（事前社内β組）の設定あれこれ #isucon で優勝させてもらってきました #isucon に参加して
NginxImageResize < Main < Foswiki
Nginx image resize configuration Nginx's image filter plugin has the ability to dynamically resize images. Caching the resized files is not yet integrated into the module, but it is possible by using an internal proxy request. This code will resize images based on the height and width given in the url, E.G. /dyn_images/sample-100-20.jpg will return sample.jpg resized proportionally to 100x20px. l
Nginx + lsyncd で WordPress を負荷分散させる - dogmap.jp
最近、め組ことデジタルキューブさんと、一緒に仕事をやらせてもらってます。 今の所は、主に WordPress サイトの高速化とかやってるんですけど、その中で WordPress サイトを複数台のサーバで負荷分散させて高速化させる案件があったので、その時の作業内容をシェア。 最近はさくらの VPS とか、低価格の VPS が出てきてるので、個人でも手を出せる領域かもしれませんね。 今回は2台のサーバを使って PHP の処理を負荷分散しました。 構成は、こんな感じです。 プライマリサーバ ( vps1.example.com : 192.168.0.1 ) Nginx, Load Balancer、PHP FastCGI のアプリケーションサーバ lsyncd (リアルタイム rsync を実現するためのサービス) セカンダリサーバ ( vps2.example.com : 192.168.0
リクエストを落とさずにnginxをアップグレードする方法とその検証
はじめに 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 など） たまにこれらのパッケージは古いものであった
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
モノヅクリブログ
NGINX Documentation
wiki.nginx.org Managed WordPress Site – Just another WordPress site
Av-jyo.com
Av-jyo.com