nginx proxyキャッシュまとめ - Qiita
http { # proxy_cache_pathとproxy_temp_pathは同じファイルシステム上に配置するのがパフォーマンス上よい # keys_zoneの1mは共有メモリのサイズ。1MiBあたり約8000個のキーを保持できるので、それほど大きくなくて良い # max_sizeは全キャッシュファイルのサイズ合計の上限 # inactiveで指定した期間内にアクセスされなかったキャッシュファイルは、その有効期間に関わらず削除される（デフォルトで10分） proxy_cache_path /var/cache/nginx keys_zone=zone1:1m max_size=1g inactive=24h; proxy_temp_path /var/cache/nginx_tmp; # オリジンから来るCache-Controlを無視する #proxy_ignore_headers
Fast resize and caching of images with "django-nginx-image" / Internet-developer workshop
For a project KinsburgTV I had to do resize images. At first I copied from one of my projects a template tag for resizing (taking roots from this snippet), but for production it is very slow solution. So I wrote another template tag, which built correct URL for Nginx, and this URL handled in ngx_http_image_filter_module and proxy_cache. I have a chart for comparison, which I did through JMeter, bu
nginx の worker_processes を auto にしたときの挙動 - やまぶろぐ
worker_processes ワーカーのプロセス数。ドキュメントを意訳するとこんな感じ。 worker_processes の最適値な、いろんな要素が複雑に絡み合っていて複雑なんや。CPU のコア数とか、負荷のかかり方とか、とにかく複雑なんや。困ったら CPU のコア数とかにしとけばええんちゃうか？あとな、auto にしとくとよしなに設定してやるやで。 よしなに…？ よしなにの中身を知りたかったのでググる "よしなに設定する" としか書いてない ソースをよんだ（怒） https://github.com/nginx/nginx worker_processes で grep それっぽいのでてきた。 src/core/nginx.c if (ngx_strcmp(value[1].data, "auto") == 0) { ccf->worker_processes = ngx_ncpu
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
nginx で gzip_static と gunzip を使ってストレージを節約する - 酒日記 はてな支店
一月ほど前に 社内Gyazoの画像をAmazon S3に逃がしてスケーラブルに運用する - 酒日記 はてな支店 というエントリを書いて一段落と思いきや、そのサーバには社内向けの nopaste アプリも同居しており、気がつけばテキストファイルが10GB以上積もっていたのでした… 社内 nopaste アプリの実装はDBなどを使用せず単にテキストファイルを保存しているだけだったので、ファイルを gzip して nginx の http_gzip_static_module を使って配信したらディスクを節約できていいんじゃないか、と思いついたのですが、Accept-Encoding: gzip でないクライアントからアクセスすると 404 になってしまうので圧縮前のファイルが消せない。 今時ブラウザで対応していないものは少ないとはいえ、curlとか各種言語のHTTPクライアントでアクセスする場
Nginx HTTP basic auth – allowing IP or password-based access - lxadm | Linux administration tips, tutorials, HOWTOs and articles
From lxadm | Linux administration tips, tutorials, HOWTOs and articles nginx uses similar syntax to that of Apache to allow users to access a directory, depending if their IP or username/pass matches (i.e. you want all users to present a valid username/pass match, but want to let some automated checks coming from specified IPs through, i.e. from ldirectord or nagios). Here is an example to use bot
Winginx - Local web server for PHP5, MySQL, MongoDB, Node.js developers
Discover a handy tool for web development! Enjoy PHP 7.1 (+ 5.6) MySQL 5.7 Node.js 6 MongoDB Redis memcached CMS and frameworks New features Project tasks Time tracking Local mail Improved server manager New nginx config Tools htaccess to nginx converter HTTP-auth password encrypter Punycode encoder Winginx © Alexei Shabalin, 2011-2023
Nginxで使える画像変換モジュール ngx_small_lightのご紹介 - pixiv engineering blog
ご挨拶エントリに引き続きインフラ兼ソフトウェアエンジニアのbokkoです。 記念すべき第一回目のエントリは拙作のソフトウェアであるngx_small_lightについて紹介させていただきます。 ngx small lightView more presentations from Tatsuhiko Kubo. ngx_small_lightは簡単に言うとNginxで画像変換を行うための拡張モジュールで、 mod_small_lightというApacheモジュールをNginx用に移植したものです。 元々pixivではサービスで使われている一部のサムネイルをpixiv用に改造したmod_small_lightで動的に生成しているのですが、 それと同時にApacheよりも柔軟な設定を記述しやすいNginxをアプリケーションサーバ群や画像キャッシュサーバ群のフロントサーバとして ヘビーに活用して
app serverがリクエストの処理にかかった時間をログに記録する
Webアプリケーションのパフォーマンスをトラッキングするために、app serverの処理にかかった時間を記録したい。 方法を、以下のように分類できる。 1. reverse proxy側で、proxy先のapp serverがレスポンスを返してくるのにかかった時間をログに記録する場合 1.1 nginx 1.2 apache 2. app serverでリクエスト処理にかかった時間を出して、ログに記録する場合 2.1 reverse proxyで記録する場合 2.2 app serverでログに記録する場合 1と2とでは出てくる数字が違うだろうけど、本件に必要なのはパフォーマンス改善を示す一貫した指標なので、どっちでもいいと思う。 1. reverse proxy側で取る場合 1.1 nginx log_formatディレクティブに$upstream_response_timeという変数
NginxのPerlモジュールで自由にリアルタイム画像変換する方法 - 9mの日記
Webサイトでいろいろなサイズの画像を使いたいとき、URLのパラメータを変えるだけでサイズ変換してくれると非常に便利です。クックパッドのTOFUとかわりと有名ですね。開発効率も上がるし、面白そうだったのでNginxで実装してみました。 TOFU : 料理を楽しくする画像配信システム フルサイズの画像 元の画像です http://pic.kksg.net/shirakawago.png 比率固定リサイズの画像 /scale/128x128 を挟むと縦横の最少が128pxの画像になります。 http://pic.kksg.net/scale/128x128.shirakawago.png サイズ指定切り抜き c オプションで切り抜き。指定サイズいっぱいに、いい感じに切り抜きます。 http://pic.kksg.net/scale/c.600x150.shirakawago.png グリッチ
Multiple Django and Flask Sites with Nginx and uWSGI Emperor - tghw.com
Posted May 16, 2012 I like Python, a lot. I'm one of those people who would use it all the time if they could, especially for web development. Which is convenient, since I'm currently working on my own company. One of the drawbacks of using Python, though, has always been getting it to play nicely with web servers. I've never been completely happy with the options out there: mod_python, mod_wsgi,
[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)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - yandex/gixy: Nginx configuration static analyzer
GitHub - cybozu/nginx-uuid4-module: nginx-uuid4-module is a nginx module to generate version-4 UUIDs.
nginxで動的に画像をリサイズする(ngx_small_light使用)
実践ngx_small_light入門
nginxのパフォーマンスチューニング
ngx_dynamic_upstreamでnginxのアップストリームを動的に変更する - Qiita
wiki.nginx.org Managed WordPress Site – Just another WordPress site
Shinobra.com