なぜ Rails の前段に Nginx を置くのか - Qiita
追記（2023.09.13） X にて、この記事が引用されて多くの議論が投稿されました。 それらの多くは以下の通り「ALB等の利用できる環境の現代であればもうNginxコンテナは不要」という内容が多数です。 その上で、本文に入って頂ければと思います。一部「いいね」が多いポストを貼り付けさせていただきます。 本文にショートカットしたい場合は、ここをクリック ここから本文 以前、チームで以下のような会話が生まれました。 「コンテナに nginx 立てずに、直で rails Appサーバに ALB から流せばいいじゃん？」 みたいな話。その際に理由を即座にレスできなかったので、調査しました。 puma や Unicorn はあくまでAppサーバなのでユーザ直アクセス用途として設計されていない バッファリング処理が弱い バッファリング処理（処理速度や処理にかかる時間の違いを調整すること） ngin
nginxでHTTP/3を使う方法 2023年5月版
ついさっき、ついにHTTP/3対応のブランチが本家のnginxにmergeされました。 このまま何事もなければ次のMainline versionである1.25.0がリリースされたタイミングで使えるようになるはずです。 検索するとnginxでHTTP/3を使う方法を解説しているサイトがいくつかヒットしますが、実はmergeするちょっと前くらいから非互換な変更をいくつも入れていたので、そのままだと動かないはずです。なので簡単に使い方を解説しておきます。 なお分かっていると思いますが、こちらの記事は記事執筆時点（2023/05/20）の内容です。 OpenSSLの代わりを選ぶ HTTP/3を使うには自分でbuildする必要があります。いずれpackageが配布されるだろうと思っている人がいるかもしれませんが、nginxのHTTP/3対応はBoringSSLのAPIで対応されています。OpenS
複雑怪奇な nginx を Go と Docker でユニットテストする - Cybozu Inside Out | サイボウズエンジニアのブログ
全国の nginx 職人のみなさま、こんにちは。野島(@nojima)です。 私の所属するYakumoプロジェクトでは、nginx を Go と Docker によってユニットテスト1しています。 手元で簡単に実行でき、ブランチへのpushのたびにCIでテストされるので、非常に便利です。 この記事では、このnginxのユニットテストについて紹介してみたいと思います。 背景 nginx は極めて柔軟なロードバランサであり、プロダクション環境ではその柔軟さを生かして多彩な役割を担っています。 我々の nginx は、ユーザーからのリクエストを AP サーバーに振り分け、アクセス制限を行い、リクエストをリダイレクトし、HTTPヘッダを付与したり削ったりしています。 しかし、nginx は便利な反面、その設定は極めて複雑になり、読解したり変更したりするのが難しくなっています。 そこで、nginx
ngx_mruby の動的モジュールをビルドするツール - 復刊 ボルシチは食べ物です。
Docker を使って ngx_mruby を動的モジュールとして手元で簡単にビルドできるようにした。 github.com 以下のようなユースケースを想定している。 すでに別のモジュールを静的モジュールとしてビルドした nginx を使っている環境に新たに ngx_mruby を導入したい。 ngx_mruby を運用する環境は Linux (CentOS) だが、ビルドは手元の Mac 等で行いたい。 ngx_mruby を組み込んだ nginx パッケージをビルドする類似のツールとして pepabo/ngx_mruby-package-builder があるけど、 1 のような他のモジュールも組み込む必要があるケースにはマッチしない。 2 のケースについては実行環境とビルド環境が揃っているならば、 ngx_mruby 付属のビルドスクリプトで十分。 使い方 クローンしてきたら mak
ngx_mruby v2のHTTPクライアントをv1よりも最大90倍高速にした - 人間とウェブの未来
写真のような感じでRubyKaigi2018で登壇し、RubyKaigiを経て、ようやくngx_mrubyのv2をリリースしました。基本的にv1と互換性がありますので、今後はv2を開発していくことになります。 github.com ngx_mruby v2の目玉機能としては、Rubyスクリプトからノンブロッキングのsleepとhttp[s]クライアントを使えるようになったことです。実装的には、nginxのsub requestという機能をうまく使って、ノンブロッキングのhttp[s]クライアントを汎用的なsub_requestメソッドとして実現しています。 では、本エントリではそのノンブロッキングhttpクライアントがどの程度高速処理可能になったかを実験してみましょう。また最後には、RubyKaigi2018の感想も述べます。 実験 proxyサーバのblockingとnon-blocki
Redirecting to ssl-config.mozilla.org...
Mozilla SSL Configuration Generator Redirecting to the updated SSL Configuration Generator…
ngx_mruby v1.20.0で動的listener設定をサポートしました - 人間とウェブの未来
タイトルの通り、ngx_mrubyのhttpモジュールとstreamモジュール両方で、mrubyによる動的Listener設定をサポートしました。 動的Listenerとは、nginxのlistenの設定をmrubyで書いて、起動時に動的に設定を読み込めるようにできる機能です。以下の例を見た方が分かりやすいかと思います。 # $ ulimit -n 60000 worker_processes 1; events { worker_connections 30000; } daemon off; master_process off; error_log logs/error.log debug; stream { upstream dynamic_server { server 127.0.0.1:8080; } server { mruby_stream_server_context_
dockerなら5分で動く！ nginxのログをfluentdで集めてnorikraでストリーム分析 - Qiita
はじめに ようへいさんのポストを参考にしてdocker上でnginxとfluentdとnorikraを動かせたので、docker indexにイメージを掲載した。dockerのある環境ならあっという間に動くはず。 準備 dockerが動くこと ホスト側でfluentd用のファイルディスクリプタ設定を済ませていること 手順 norikraを動かす まずはログの集約先となるnorikraを動かす。 $ sudo docker run -p 26578:26578 -p 26571:26571 -p 24224:24224 -p 24224:24224/udp -d kazunori279/fluentd-norikra-server $ sudo docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 7874efdd2e
G-WANはなぜ速いのか？をnginxと比べながら検証してみた - blog.nomadscafe.jp
ツチノコブログの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
高速WebサーバのNginx、ミッションクリティカル対応の商用版「NGINX Plus」リリース
オープンソースのWebサーバとしてコンパクトで高性能なソフトウェアとして知られるnginx（エンジンエックス）の開発元Nginx.incは、ミッションクリティカルな用途に対応した商用版の「NGINX Plus」をリリースしました。 The High Performance Reverse Proxy, Load Balancer, Edge Cache, Origin Server | NGINX As business requirements continue to evolve rapidly, such as the shift to mobile and the explosion of dynamic content on the Web, CIO’s are continuously looking for opportunities to increase applicat
WebSocket アプリの負荷分散 : DSAS開発者の部屋
最近 SPDY と WebSocket がアツいですね。 再来週の SPDY & WS 勉強会 も、定員100名に対して 参加者が 247 名とかなりアツいことになっています。 その予習というわけでもないですが、最近 WebSocket を実サービスへの 導入方法を考えながら遊んでいたので、 WebSocket の負荷分散方法について 考えていることを書いておこうと思います。 ステートフルな WebSocket アプリケーション HTTP サービスは基本的にステートレスな実装になっており、リクエストが来るたびに DBサーバーや memcached などのバックエンドから情報を取得して返していました。 この構成では Web アプリ自体は完全にステートレス化することができているので、 負荷分散機はラウンドロビン等のアプリケーションを無視した負荷分散をすることができました。 しかし、 WebSo
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の優雅な再起動 « NAVER Engineers' Blog
こんにちは開発チームの崔珉秀と申します。 今回はnginxというウェブサーバーについて話をさせて頂きます。 nginxは最近数年の間けっこう人気が高くなっています。特によく使われているApacheやLighttpdなどのウェブサーバーと性能の面で比較することがよくありまして、優れた性能で単純なstaticファイルを転送するウェブサーバーからCGIサーバー、reverse proxyサーバーなどの様々なウェブリクエスト処理に関わる分野で導入されています。 今日はnginxの性能の比較よりもサーバーの開発者(nginx module)もしくはサーバーの運営者としてのnginxにある仕組の中で一つを紹介したいと存じます。 サーバーの開発や運営をする場合ロジックや設定などの変更により配布の後、サーバーを再起動することがあります。 その再起動の時にウェブサービスとしてリクエストの処理を続けなが
さくら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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://tech.pepabo.com/2016/12/02/ngx_mruby_dynamic_cache/
Av-jyo.com