NGINX Amplify雑感 - Innovator Japan Engineers’ Blog
はじめまして @hacktk です。 NGINXが提供するパフォーマンス監視ツール、NGINX Amplifyがパブリックベータになったので試してみました。 手元にVirtualBox上のCentOS 6.6があったので、それを使います。 アカウント登録 NGINXのアカウントを持っていない場合はまず登録する必要があります。 トップの [SIGN UP FOR FREE] から 各情報を入力して [Sign up] メール認証を済ませましょう ログイン エージェントインストール Amplifyはエージェントを常駐させて情報を集めるタイプなので、対象のシステムにエージェントのインストールが必要です。 ログインすると親切にインストール手順が表示されます。対象のシステムで実行してみます。 [Graphs] タブに対象システムのメトリクス一覧が表示されました。 いろいろ使ってみます Graphs
nginx の設定をレビューするときの観点をまとめてみた - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。 インフラチームの野島（@nojima）です。 チームのメンバーに nginx の設定について気をつけるべき点を共有するために、レビュー観点を書きました。 せっかくなのでここで公開します。 ほとんどの項目は自分やチームのメンバーの実体験に基いています。 レビュー観点 server server_name が他のやつと被っていないか。 listen する IP アドレスが同じ場合、server_name で区別できないといけない。 TLS を使う場合、SNI をサポートしないクライアントでは TLS 用の設定が default_server のものが使われる点にも注意。 TLS を使う場合、listen ディレクティブに ssl オプションを書いているか。 location location のマッチの順番に注意 正規表現の location は前方一致の location より
nginxをWebSocketのリバースプロキシとして使う - the glue
経緯 WebSocketを使ったアプリケーションを作ったが、ポートが80しか使えない nginxでどっちも80に流したい ポイント / はまり所 WebSocketのプロキシにはUpgradeヘッダ(HTTP 1.1)への対応が必要 Upgradeヘッダへの対応は nginx v1.3.13以降 参考: WebSocket proxying 厳しい条件から先に書く デフォルトだと30秒通信がないと切断される（！） nginxでリバースプロキシしているときだけ一定時間で接続が切れるので何かと思えば、 普通のHTTPの通信と同様に30秒（だったはず）通信がなかった場合はタイムアウトってことで自動でコネクションを切ってくれていたみたい。 ping/pongを30s以内にやればいいんだろうけど、とりあえず5分に設定。 config server { listen *:80 default_serv
Nginx導入時やること - Qiita
HTTPレスポンスヘッダにサーバのバージョンの表示を消す なぜ必要？ 潜在攻撃者への情報提供になることも。 もし使用中バージョンの脆弱性が明らかになった時、恰好の標的になるとか。 対応 nginx.confのhttpディレクティブに server_tokens off; を追加。
Nginxモジュール開発メモ
Nginxのモジュール開発についてのメモ書きです。今後追加することが当分なさそうなので、現在の状態を公開します（公開できない部分は削除済み）。 目次 1. 謎のtフォルダと.tファイル（テスト方法付き）2. 最低限のモジュール構成とビルド3. 公式からリンクされている開発者向け資料4. Nginx Developers Kit5. （割と）簡単なモジュール5.1. 公式のサードパーティー製モジュールのページ6. Nginxのビルド7. Proxyモジュールについて スポンサーリンク 謎のtフォルダと.tファイル（テスト方法付き） 公開されているモジュールには謎のtフォルダと拡張子.tのファイルがあるが、これはテスト用のファイルらしい。 nginxモジュールのテストを書く - 波打際のブログさん 最低限のモジュール構成とビルド 新しい単純なディレクティブを１つ定義しただけのモジュールとビルド
Emiller’s Guide to Nginx Module Development
Emiller’s Guide To Nginx Module Development By Evan Miller First published: April 28, 2007 (Last edit: August 11, 2017 – changes) Bruce Wayne: What’s that? Lucius Fox: The Tumbler? Oh… you wouldn’t be interested in that. To fully appreciate Nginx, the web server, it helps to understand Batman, the comic book character. Batman is fast. Nginx is fast. Batman fights crime. Nginx fights wasted CPU cyc
NginxでのModuleの作り方 - よねのはてな
Apacheモジュール作成は以前のエントリの通り手軽に出来ます。 Apacheモジュールの作成とgdbとloggerでのデバッグ方法 - よねのはてな 今回は、Nginxでモジュール作成してみたいという人向けです。 Nginxにおける処理の流れと押さえておきたい構造体、モジュール作成方法をのせておきます。 Nginx http://nginx.net/ そもそもNginxってなんだ？という人は軽量超高速なHTTPサーバという理解でOKです。 実際にはReverse Proxy、Mail Proxyとしても使用可能で、ライセンスはNSD系。 Nginxについては以下を参照下さい。 パフォーマンス比較 http://www.joeandmotorboat.com/2008/02/28/apache-vs-nginx-web-server-performance-deathmatch/ Ngin
nginxパフォーマンスチューニング〜静的コンテンツ配信編〜 - Qiita
今回はHTMLやCSS、Javascriptといった比較的軽量な静的コンテンツの配信をnginxでやるケースに絞ってチューニングする際のポイントについて紹介しようかと思います。 (注：worker_rlimit_nofileやsysctl.confのネットワーク周りの設定のような定石的なチューニングについてはあえて解説しないのであらかじめご了承ください。) コンテンツをgzip圧縮する 何はともあれgzip圧縮です。ネットワーク帯域に比べればCPUリソースなんて安いものです。 しかし、多くの場合これだけでは十分ではありません。何故ならnginxはデフォルトではContent-Typeがtext/htmlのコンテンツしか圧縮しないためです。圧縮対象のContent-Typeを増やすにはgzip_typesを使います。 単純なWebサイトであれば上記の設定で十分ですが、場合によってはappli
Nginxを改造して欲しかった画像サーバーを作った | nonomura.jp
スマートフォンサイトに向けての最適化だったり、 Webページのレイアウトの変更だったりで、 同じ画像でも様々なサイズを利用することがある。 サイトの運用を続けていると、 同じ画像でも数通りのファイルを保存していて、 ファイル数が大量になってIOがキツくなってきた。 数多くなるとIO辛いから、 ファイル増やさないように気をつけてね、 と社内で言い続けていたら… Webサイトでは、本来小さい画像で良いところに 大きい画像を使用して、 JavaScriptでリサイズする処理が多用されはじめ、 今度は転送量が増加しはじめて、 これ以上増えるとデータセンターの月額費用が 増加してしまいそうに…。 なんとかせねば！と対応をはじめるわけです。 そこでまず最初にやったのが、 本当は速いImageMagick と同じように、Apacheモジュールを自作して、 ImageMagic
nginx最大パフォーマンスを出すための基本設定 | Node.js技術
解説 worker_processes auto; - Nginx本体のプロセス数、autoにしてnginx内部判定に任せるのは賢明 worker_rlimit_nofile 100000; - workerプロセスが最大に開けるファイル数の制限。このように設定したら、ulimit -a以上のファイル数を処理できるようになり、too many open files問題を回避できる worker_connections 2048; - 一つのworkerプロセグが開ける最大コネクション数 multi_accept on; - できるだけクライアントからのリクエストを受け取る use epoll; - Linuxカーネル2.6以上の場合はepoll、BSDの場合kqueue server_tokens off; - セキュリティ対策です、エラー画面のnginxバージョン番号を非表示 sendf
サーバをメンテする時に便利な Linux コマンド 3つ - bekkou68 の日記
はじめに サーバを運用したり環境を構築したりしていて「あれ。あのプロセスで吐いてるログどこだっけ・・」など困るときがあります。 そんなときに頼りになるかもしれないコマンドを 3つご紹介します。 @madeth 師匠に教えていただきました。 1. proc でプロセスが使っているファイルを見る 困ったこと プロセスの吐くログのパスがどうしても分からない・・。 解決法 (編集 2014/09/10) 知りたいプロセスの ID を調べます。 $ ps aux | grep unicorn deploy 3335 xxx xxx xxx xxx X XX 15:14 0:07 unicorn master -c /var/www/myproject/unicorn/staging.rb -E staging -D プロセスID (この場合は 3335) をもとに root 権限でファイルディスクリ
Nginx導入時、サクッと対応しておくと良いかもしれない - Qiita
HTTPレスポンスヘッダにサーバのバージョンの表示を消す なぜ必要？ 潜在攻撃者への情報提供になることも。 もし使用中バージョンの脆弱性が明らかになった時、恰好の標的になるとか。 対応 nginx.confのhttpディレクティブに server_tokens off; を追加。
LTSVをNginxで使ってみる - Hidden in Plain Sight
id:stanaka のLTSVがバズってるみたいなので乗ってみた。（Hacker Newsにもポストしたんだけど、瞬時に流れてしまったよ。。） Nginxでの設定を（主にキーの命名で）1時間ぐらい試行錯誤した結果、とりあえず以下に落ち着いた。 log_format ltsv 'ts:$time_iso8601\t' 'ip:$remote_addr\t' 'method:$request_method\t' 'path:$request_uri\t' 'status:$status\t' 'size_req:$request_length\t' 'size_res:$bytes_sent\t' 'size_body:$body_bytes_sent\t' 'time_req:$request_time\t' 'time_app:$upstream_response_time\t' # '
Dropbox のスケールとか
Python なサービス みんな大好き Dropbox のスケールとかメモ。以下のページ辺りからピックアップ。Parted? みたいなので、続編がでたら追記するかも。 Scaling lessons learned at Dropbox, part 1 (comment) Dropbox - Startup Lessons Learned (slideshare) Dropbox -Yコンビネーターが生んだスタートアップの軌跡と未来 - スケール関係ないですが、2006 年当時はオンラインストレージサービスがいっぱいあったようで、VC から資金調達したときのやり取りがおもしろい VC "クラウドストレージサービスなんて腐るほどある" Drew "なにか使ってるのありますか？" VC "NO" Drew "..." 完璧で、スケーラブルで、クロスプラットフォームなクラウドストレージ！当時、プ
nginx - locationの文字列と正規表現の優先順位 - うまいぼうぶろぐ
http://wiki.nginx.org/NginxHttpCoreModule#location 少しはまった。正規表現の設定のほうが後で評価されて、設定が上書きされるのか。そういえば、apacheもそうだったかな？ 例 URL: /fooにaliasを設定しているとする。で、/foo以外の画像(正規表現で指定)へのリクエストはreverse proxyしたいとする(/foo/bar.jpgはreverse proxyさせずにaliasで設定しているdirectoryから配信したい)。 この場合、/fooの設定は"location /foo"ではなくて、"location ^~ /foo"じゃないとダメ。 ###### 設定A # location /foo { # 間違い location ^~ /foo { alias /path/to/foo; index index.html
さくらVPSのWordPressをチューニングして30倍高速化した方法 - 原宿・表参道.jp
今日はさくらVPSに載せているWordPressのパフォーマンスをチューニングして高速化に成功したので安心して眠れるという話をします。 2.5ページ/秒だったのが70ページ/秒と30倍高速化。 以前はDaily数千PVで重くなっていたサイトがDaily3.6万PVを余裕で捌けるようになりました。 #ちなみにproxy cacheという手法はwordpressでなくても動的コンテンツ全般に有効です。 ▼サーバ気にしなくて良くなったので今週末新宿御苑に花見に行けました☆。枝ぶりがいいさくらが多くてほんといいところだと思うの。 WordPressチューニング高速化結果http://hara19.jp/のサーバ環境と測定結果は以下のとおり。 WordPress稼働環境さくらVPS 1GB/CentOS5.5/PHP5.3/MySQL5.5/WordPress3.1。 WEBサーバはチューニングにあ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
nginxのパフォーマンスチューニング
Sass を今すぐ実務で使おうよ！ « LINE Engineers' Blog
httpsだからというだけで安全？調べたら怖くなってきたSSLの話!？ - Qiita
イイ:モバイル
