Nginxチューニング nginx最大限にスピードを出すために、設定パラメーターをチュニングしました。 nginx設定例 user www-data; pid /var/run/nginx.pid; worker_processes auto; worker_rlimit_nofile 100000; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; events { worker_connections 2048; multi_accept on; use epoll; } http { server_tokens off; sendfile on; tcp_nopush on; tcp_nodelay on; access_log o
しょっちゅう必要になるので、メモ書き程度に 参考にしたのは、以下の URL です。 Apache Webサイトのメンテナンス中画面を出す正しい作法と.htaccessの書き方 | Web担当者Forum Nginx nginx: Create HTTP 503 Maintenance Custom Page nginxで特定ホスト以外からのアクセスをメンテナンス画面にする方法 (2) – (ひ)メモ Nginxでrestart, reloadをすることなくメンテナンス画面に切り替える – Qiita 前提としてメンテナンス中画面として表示する際に使用する html は以下のファイルを使うものとします。 maintenance.html style.css /img/corp_logo.png また、以下の IP アドレスからのアクセスは管理者からなのでメンテナンス中画面を表示しないものとし
[カテゴリ:開発] configure option try_files SSL証明書と中間証明書 パスを切り取ってからproxyへ 変数とif Basic認証 無停止upgrade 変数の使える場所 使えない場所 使える場所 変数は参照渡し! error_page の怪 rewrite と query_string port_in_redirect off configure option./configure --prefix=/usr/local/nginx-0.7 \ --conf-path=/etc/nginx/nginx.conf \ --error-log-path=/var/log/nginx/error.log \ --pid-path=/var/run/nginx/nginx.pid \ --lock-path=/var/lock/nginx.lock \ --user
とある事情により、POST リクエストをリダイレクトさせる必要が生じました。単純にリダイレクトさせてみたところ、リダイレクトはされるものの、POST リクエストに付与していた HTTP_BODY が取得できません。どうも、リダイレクト時に GET に変更されているみたいです。 ぼくは怒りに震えたものの、RFC 的にはどう振る舞うべきなんだ、各種ブラウザの振舞いはどうなっているんだ、ということが気になったのでまとめてみました。内容としては、 -POSTリクエストをリダイレクトするとGETされる?POSTされる? - はこべにっき ♨ の二番煎じになります。 先に結果を示しておくと、以下のとおりでした。 Status Code 期待動作 Firefox (25.0.1) Safari(7.0) Chrome (31.0) 301 POST GET GET GET 302 POST GET GE
Webサーバーがレスポンスを発行する際に、HTTPレスポンスヘッダーに付けるとセキュリティレベルの向上につながるヘッダーフィールドを紹介します。 囲み内は推奨する設定の一例です。ブラウザによっては対応していないヘッダーフィールドやオプションなどもありますので、クライアントの環境によっては機能しないこともあります。 X-Frame-Options ブラウザが frame または iframe で指定したフレーム内にページを表示することを制御するためのヘッダーフィールドです。主にクリックジャッキングという攻撃を防ぐために用いられます。 X-Frame-Options: SAMEORIGIN DENY フレーム内にページを表示することを禁止(同じサイト内であっても禁止です) SAMEORIGIN 自分自身と生成元が同じフレームの場合にページを表示することを許可(他のサイトに禁止したい場合は主にこ
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
このブログのバックエンドApacheからNginxに乗り換えたので、それまでの流れをメモとして公開します。Nginxをわざわざ使う上でやっておいたほうがいい基本的な設定とリバースプロクシキャッシュの動く設定からベンチマークツールの賛否両論まで。 次世代WebサーバーのNginxという未来へ! 「Nginxがすごい!!!」みたいな話を聞いて、はや4年。なんだかよくわからず、Apacheを使い続けていましたが、やっとNginxのすごさがわかったので、乗り換えました。そのあたりのより入門的な内容やApacheでよくやる設定をNginxでどうやろうかもつらつら調べているので、そのあたりは別記事としてたぶん公開するとして、まず手っ取り早く導入しないとそのあたりをやる気力もなくなるので、個別のカスタマイズはさておき、導入内容ついて記事にしておきます。とりあえず、Nginxの公式サイトでも見てみるといい
NGINX Plusでできることをまとめてみた。 NGINX Plusとは NGINX Plusはみんな大好きオープンソースHTTPサーバであるNginxのサポート付き商用版である。Nginxを開発しているNginx Inc.が提供している。とはいえ、サポート付きというだけではなく次のような機能が増えている。なお、下3つについてはあまり興味がなかったので、今後説明がでてくることはない。 ステータス、レスポンスなどによる高機能なヘルスチェック - Application health checks JSON/JSONPで取得できるステータス - Activity monitoring HTTP APIでノードを追加/削除できる - On-the-fly reconfiguration HLS対応 - HTTP Live Streaming (HLS) HDS対応 - HTTP Dynamic
前回の記事でCloudFront + S3でgzipで圧縮する方法について書きました。 CloudFrontでgzip圧縮したデータを転送する - おぎろぐはてブロ オリジンがS3の場合、CloudFrontで動的にgzipしたりgzip版を応答してくれたりはせず、ノーマルとgzip版両方をS3にアップして、リンクを張る側で、クライアントのヘッダみて、URLを切り替えろということで、微妙です。 たとえば、ユーザがデータをアップロードするような場合、両方をアップロードしてもらうわけにもいかないので、アップロードしたあとに、S3にgzip圧縮したデータを別途アップしないといけません。 ということで、その解決案として、CloudFrontとS3の間にgzip圧縮するサーバをはさむのを試してみました。 まずレスポンスの確認 S3においたファイルと、それをオリジンにしたCloudFrontディストリ
というメモ。 server { listen 80; server_name example.com; root /path/to/docroot; access_log logs/example.access.log main; location ~ ^/(js/|img/|css/|swf/) { index index.html index.htm; } error_page 404 /404.html; error_page 500 /500.html; error_page 503 /503.html; location ~ /(404|503|500).html { } location / { proxy_intercept_errors on; proxy_set_header Host $host; proxy_pass http://127.0.0.1:5000; }
一般的に利用されるブラウザではJavaScriptによるクロスドメイン制約などセキュリティのための読み込みドメインの制約があります。 そのためクラウド上のファイルなどを利用するときに上記の制約を受けて何らかの対策が必要になる場合があります。 この対策の一つとしてリバースプロキシによって対応する方法があります。 リバースプロキシを立ててすべてを解決するんだ リバースプロキシで解決を試みると言うのは以下の図のような構成にすることです。 このようにリバースプロキシを使うことでユーザのブラウザから見るとすべてのデータが同じドメインからのデータ取得になります。 このような構成にするために次に具体的な設定をしてみます。 リバースプロキシを立てよう リバースプロキシを立てるにはApache、Squidなどの有名なWebサーバやProxyサーバを利用したり、最近ではnode.jsでスクリプトを書いて
2013年05月22日10:28 chef-solo で ngx_pagespeed 組み込み nginx をインストール カテゴリ Tweet 目下 入門Chef Solo - Infrastructure as Code を読み進めつつ、vagrant で仮想サーバーを起ち上げながら試行錯誤しているんですが、サードパーティ製の nginx cookbook に ngx_pagespeed モジュールを追加、ngx_pagespeed を --add-module してインストールするようにフォークしてみました(*1)。 https://github.com/wata/chef-nginx 使い方Berksfile に、 chef-repo/Berksfile site :opscode cookbook 'yum' cookbook 'nginx', git: "https://git
For this configuration you can use web server you like, i decided, because i work mostly with it to use nginx. Generally, properly configured nginx can handle up to 400,000 to 500,000 requests per second (clustered), most what i saw is 50,000 to 80,000 (non-clustered) requests per second and 30% CPU load, course, this was 2xIntel Xeon with HT enabled, but it can work without problem on slower mach
Discover install links, docs, and support options for open source server modules that optimize your site automatically.
本記事は英語版のブログで2011年3月29日に公開された記事の翻訳版です。 私は Rails での作業に満足していますが、仕事に合った正しいツールを使うことも大事だと考えています。多くの開発者が Rails アプリケーションにリダイレクトを追加しますが、開発段階では便利でも、いざ本番環境でのトラフィックが開始されると上手くいかない場合があります。当社では、フロントエンドのリバース プロキシとして Nginx ウェブ サーバーを使用しています。一般的なリダイレクトを Nginx に移して Rails の負担を軽減し、本来のタスクを行わせることが簡単にできます。 たとえば、最初にフォーカス グループでは名前が覚えにくいと言われ、SEO の教祖様にはドメインに www を含めなければならないと批判され、ユーザービリティ担当者からは一般的な入力ミスを検知すべきだと言われたとしましょう。最初のうちは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く