秒間50kリクエストを捌くノウハウがこの1冊に！nginx実践入門 - pixiv inside [archive]
こんにちは、@harukasanです。ピクシブでは3年以上にわたってHTTPサーバにnginxを採用しています。これらのノウハウが詰まった「nginx実践入門」が1/16(土)、技術評論社から発売されることになりました。 この記事では本書からピクシブで良く使われているnginxのテクニックについてかいつまんで紹介します。 すべてのリクエストを受け止めるnginx ピクシブのたくさんあるサービス（pixiv、pixiv Spotlight、pixivコミック、ピクシブ百科事典……）のどこかにHTTPリクエストを投げると、複数台あるフロントサーバのどれかに届きます。実際にアプリケーションを処理するのはフロントサーバの裏側にいるアプリケーションサーバです。これらのサーバにはPHPだったり、Ruby on RailsだったりPlay/Scalaだったりいろんなアプリケーションがデプロイされています
![秒間50kリクエストを捌くノウハウがこの1冊に！nginx実践入門 - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/e3cbfd0838fff5d53ac2fa7e2c6499b71dfee893/height=288;version=1;width=512/http%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fh%2Fharukasan%2F20160115%2F20160115160510.jpg)
ハイパフォーマンスngx_lua | メルカリエンジニアリング
Site Reliability Engineering（SRE） Teamの@cubicdaiyaです。 今回は数あるnginxのサードパーティモジュールの中でも一際強力で、メルカリでも活用しているngx_luaの便利な活用方法や最適化集について紹介します。 ngx_luaは軽量スクリプト言語のLuaでnginxを拡張できるモジュールです。 nginxの設定ファイル内にLuaのコードを埋め込んだり、nginxの拡張モジュールをCではなくLuaで開発することができます。以下はngx_luaにおける「Hello, World!」です。 location / { content_by_lua 'ngx.say("Hello, World!")'; } 上記のロケーションにHTTPでアクセスするとnginxはボディが「Hello, World!」のレスポンスを返します。 なお、先月末にリリースさ
H2OとPHPを組み合わせるの、超簡単です（もしくはmod_rewriteが不要な理由）
FastCGI対応機能がH2Oにマージされたことを受けて、uzullaさんが「H2OでPHP（がちょっとだけ動くまで）」という記事を書いてくださっています。 ありがたやありがたや。 その中で、 http://hoge/entry/1 みたいなのをphpにマップする方法はまだよくわかってません。その内しらべます github.comを読む限り FastCGI (or PHP) applications should be as easily configurable as it is for the Apache HTTP serverということで、やったぜ！ってなるんですけど、nginxはもとより、Apacheにおいても現状ルーターをつかっているようなアプリだとhtaccessをいちいちかかないといけないので、Apacheみたいなスタイルが楽なのか？というとちょっと疑問があります。 （たと
NGINX IMAGE SERVER
2015/02/18 画像変換Night にて ngx_small_light を使った動的画像変換の事例を発表した際の資料です。 http://connpass.com/event/11516/ 画像サーバは Docker イメージを用意しています。 https://github.com/wantedly/nginx-image-server An usecase of image processing server with Nginx and ngx_small_light. Image processing server is available as Docker images under the wantedly organization. https://github.com/wantedly/nginx-image-server
複数の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モジュールを使う
ApacheとNginxの性能比較でevent_mpmの本気を見た
はい、これは僕がいつも良く見るApacheとNginxの性能差に見えます。大体、ApacheはNginxの75%程度の性能に落ち着きます。数十バイトの静的コンテンツに対するリクエスト処理はNginxの得意分野だと思っていたので、大体こんなものです。 そこで、真面目にevent_mpmのチューニングを行ってみました。で、幾度となくベンチを試した結果導き出した、静的コンテンツに対する同時接続数100程度に対して最高のパフォーマンスを示すevent_mpmの設定は以下のようになりました。 [program lang=’apache’ escaped=’true’] StartServers 4 MinSpareThreads 4 MaxSpareThreads 4 ThreadsPerChild 2 MaxRequestWorkers 2 MaxConnectionsPerChild 0 [/p
nginxをリバースプロキシで使うならKeepAliveするべき - uokadaの見逃し三振は嫌いです
タイトルは釣りでnginxにかぎらずリバースプロキシ使うならって話。 高負荷サイトのフロントにnginxをリバースプロキシとしてたてて後ろのサーバーへリクエストをなげていたら数百rpsでいろいろなエラーがnginxのログに落ちてきた。 その時にとった対策を少しまとめてみる。 まず、nginxのエラーログに下のようなエラーの対処法。 nginx: [emerg] bind() to 127.0.0.1:8080 failed (99: Cannot assign requested address) $ netstat -an |grep TIME_WAIT |wc このときのwcの結果は2万数千あり、詳細を調べていくとその中の大部分が後ろのサーバーからnginxにリクエストを返すために利用したポートがほとんどであった。 これを解消するための対策として一番手っ取り早いのがカーネルのチューニン
Apacheをnginxにリプレイスした
yubitterという携帯向けTwitterクライアントサービスで、ユーザーのアイコンを携帯電話向けに変換している(※1)、いわゆる画像変換サーバーのhttpd部分をApacheからnginxへ変更しました。 処理は単純に以下の流れです。 クライアントからアイコン画像のリクエストが来る 既にハードディスクにキャッシュファイルがある場合は、それをそのまま返す ファイルがない場合は、PHPプログラムがアイコン画像がアップロードされているTwitterのサーバー（現在はAmazon S3/CloudFront）へ取りに行く PHPプログラムが取得した画像データをGDライブラリを利用して加工、ハードディスクに保存、レスポンスを返す 変換するにあたり、以下の2パターンを検討しました。 リプレイス案1は、Apacheのレイヤーを一つ下げてAPサーバーに専念してもらう案で、2案は、Apache+mod_
我々はどのようにして安全なHTTPS通信を提供すれば良いか - Qiita
HTTPS通信は複数のプロトコル、手法が組み合わされて実現されている。そのため、暗号化手法それぞれのリスク、ブラウザの対応等様々な用件があり、全てを理解するにはちょっと時間とリソースが足りない。結局のところ、我々はどのようにして安全なHTTPS通信を提供できるのか。色々調べていたところ、MozillaがMozilla Web siteに使用する、HTTPSの推奨設定を公開している。 Security/Server Side TLS - MozillaWiki このドキュメントはMozillaのサーバ運用チームが、Mozillaのサイトをより安全にするために公開しているもので、他のサイトにそのまま適用できるかは十分に注意する必要がある。例えばガラケー向けサイトとか。そのまま使えないとしても、HTTPS通信の設定をどうすれば良いか、理解の一助になるはずだ。 この記事は上記MozillaWiki
nginx+Unicornでサブディレクトリでアプリを動かす - ひげろぐ
Passengerだと簡単だったけどUnicornだとちょっと手こずった。 nginx側 ディレクトリの準備 nginxのroot以下に任意の名前のサブディレクトリを作る。 これはRalisアプリケーションのpublicディレクトリのシンボリックリンクにする。 cd /var/www/root ln -s /var/www/my-app/current/public my-app （Capistranoを使っているのでこの例ではcurrentがついている） nginxの設定 nginxのupstreamとserverの設定を抜粋。 upstream unicorn-of-my-app { server www.example.com:8080; } server { listen 80; server_name www.exemple.com root /var/www/root; err
nginx連載3回目: nginxの設定、その1
ディレクティブはこのモジュールのカテゴリ毎に記述します。ただし、coreモジュールに関してはmainコンテキスト、すなわち、設定ファイル内の最上位の階層に記述します。設定ファイルの構成は次のようになります。 coreモジュールの設定 events { eventモジュールの設定 } http { httpモジュールの設定 } mail { mailモジュールの設定 } httpコンテキストはさらに、バーチャルサーバ（バーチャルドメイン）毎の設定を行うserverディレクティブ、さらにURI毎の設定を行うlocaltionディレクティブにより階層化されます。次のような構成になります。 http { httpモジュールの設定 server { サーバ毎の設定 location PATH { URI毎の設定 } location PATH { URI毎の設定 } ... } server { .
さくらVPS Capistrano編 - プログラミングノート
基本設定、開発環境設定に引き続き、今回はCapistranoを導入して自動デプロイできるように設定。unicorn+nginx周りの設定も変更して快適にデプロイできるようになりました。 リモートリポジトリの作成 リモートサーバーにリポジトリを作成します。 今回は全て同じサーバーでやるので、自分のホームディレクトリ直下に作りました。 $ mkdir -p /home/ntaku/git/sample $ cd ~/git/sample $ git --bare init 後からcapistranoでアプリを配置するためのディレクトリも作成しておきます。 # mkdir /var/www プロジェクト作成 ここからはローカルで。 新規プロジェクトを作成して、テスト用のコントローラーを追加します。 $ rails new sample -d mysql $ cd sample $ rails g
apache,nginx × passenger,unicornのベンチをとってみた
preforkでテストしました。 yumでインストールした状態で使ってます。 最後にテスト用のconfをincludeしています。 httpd.confKeepAlive Off 〜 StartServers 8 MinSpareServers 5 MaxSpareServers 20 ServerLimit 256 MaxClients 256 MaxRequestsPerChild 4000 〜 Include /home/homepage/hello_world_rack/hello_world_rack_apache.conf hello_world_rack_apache.conf passengerのテストの場合は、VirtualHostまで使ってます。 unicornをテストする場合は、VirtualHostまでをコメントアウトし、ProxyPassのところのコメントアウトを
lua-nginx-module の紹介 ならびに Nginx+Lua+Redisによる動的なリバースプロキシの実装案 - hibomaの日記
Nginxは非常に強力なhttpdですが、独自のモジュールを実装しようとするとこれまた非常に敷居が高い印象です。 追記 この記事よりも前に http://openresty.org/#DynamicRoutingBasedOnRedis でほとんど同じ内容のエントリが書かれていました。こちらも参照ください モジュールの開発はむずかしい まず開発用のドキュメントはほとんどありません。必然 既存のモジュールをお手本としますが、コメントも少ないのでソースだけが頼りです。 {ファイル,ネットワーク} I/O を伴う処理では、Nginxのノンブロッキング/イベントドリブンのアーキテクチャにのっとってコールバックを駆使したCで実装する必要があり、LLで育ったゆとり脳では太刀打ちできませんでした lua-nginx-module が代わりになるかも なんらかのNginxモジュールを開発しなければならない
[nginx] nginx で upstream を active backup 構成 - 酒日記 はてな支店
nginx で振り分けるのに、いままで自分の作った構成だと backend はすべて active でロードバランスしてたけど、都合により active-backup 構成にしたくて調べたら簡単だった。一応メモ。 HttpUpstreamModule - Nginx Community backup - (0.6.7 or later) only uses this server if the non-backup servers are all down or busy upstream server の定義に backup を付けておくと、それ以外のが全て落ちたときだけ振り分けられる。 upstream backend { server 127.0.0.1:5000; server 127.0.0.1:5001 backup; }
![[nginx] nginx で upstream を active backup 構成 - 酒日記 はてな支店](https://cdn-ak-scissors.b.st-hatena.com/image/square/42c097f3027b4dc8146002d2087dd51d1d697b24/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F13208692334729889028%2F8454420450078126225%2F1419604156)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
