nginx(1.3.13)でWebSocketのプロキシを試してみました 2013/2/19にnginxが正式にWebSocketに対応したとアナウンスがあったので、試しに使ってみました。 ダウンロード・インストール ここからnginx-1.3.13をダウンロードしてきて、インストールします。 インストールオプションはあえてデフォルトで $ wget http://nginx.org/download/nginx-1.3.13.tar.gz $ tar xvf nginx-1.3.13.tar.gz $ cd nginx-1.3.13 $ ./configure $ make $ sudo make install 設定ファイルの書き換え 次にnginx.confを書き換えます。構成は リバースプロキシ: 192.168.0.8:80 バックエンドサーバ: 192.168.0.2:3000
nginx では1プロセスで多くのアクセスを捌くので、アクセス数が増えるとToo many open filesエラーが発生することがあります。 ここでは対処法と調べた内容を残しておきます。 1. fs.file-max の確認 まず fs.file-max の値を確認しておきます。fs.file-max は、システム全体でのファイルディスクリプタの上限数となっており、この値以上のファイルディスクリプタは確保することができません。 現在設定されている値は以下で確認できます。 $ cat /proc/sys/fs/file-max 167488 通常は上記の値で問題無いと思いますが、もしこの値が不足しているようなら設定値を更新します。 $ sudo -s # echo 320000 > /proc/sys/fs/file-max # cat /proc/sys/fs/file-max 320
インフラエンジニアのoknuです。 ブログ内容的にインフラに偏ってるので、言わなくてもいいかなーと思ってます。 それでは、さっそくですが nginxのことについて、ブログに書いてほしいみたいなリクエストがあったところに nginxの分散方式でleast connectionが使えるようになってたことに気づいて 検証して、OKそうなら採用しようということで検証をはじめました。 検証環境 nginx1.2.4 CentOS 6.3(64bit) nginxのアップデート # yum update nginx 検証用 webサーバ bl_testserver.py 検証用のwebサーバはpythonでざっくり書きます import BaseHTTPServer,CGIHTTPServer import sys def run(server_class=BaseHTTPServer.HT
はい、これは僕がいつも良く見る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
HTTPガイドHTTP の概要典型的な HTTP セッションHTTP メッセージMIME タイプ（IANA メディア種別）HTTP の圧縮HTTP キャッシュHTTP 認証HTTP Cookie の使用HTTP のリダイレクトHTTP 条件付きリクエストHTTP 範囲リクエストコンテンツネゴシエーションHTTP/1.x のコネクション管理HTTP の進化プロトコルのアップグレードの仕組みプロキシサーバーとトンネリングHTTP クライアントヒントHTTP セキュリティサイトの安全化HTTP ObservatoryPermissions Policy Experimental コンテンツセキュリティポリシー (CSP)オリジン間リソース共有 (CORS)Cross-Origin Resource Policy (CORP)ヘッダーリファレンスHTTP ヘッダーAcceptAccept-CHAc
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 久々のApache HTTP Server 2.4.1という安定版がリリースされたので、早速ベンチマーク評価を行う。今回はevent_mpmのExperimentがとれて、晴れてデフォルトMPMになったのでそれを使ってみたい。 日本一（ひょっとすると世界一）早いApache 2.4.1 event_mpmのレビューを意識してみた。 はじめに 個人的にも、event_mpmが採用されたことに最も注目している。event_mpmは非同期型のIO処理をしていて、nginxに近いアーキテクチャをとっている。厳密には、nginxの非同期と比べた場合、nginxは徹底的にノンブロッキング（accept4を使う等）してworkerスレッドで次々と並列処理し
こんにちは開発チームの崔珉秀と申します。 今回はnginxというウェブサーバーについて話をさせて頂きます。 nginxは最近数年の間けっこう人気が高くなっています。特によく使われているApacheやLighttpdなどのウェブサーバーと性能の面で比較することがよくありまして、優れた性能で単純なstaticファイルを転送するウェブサーバーからCGIサーバー、reverse proxyサーバーなどの様々なウェブリクエスト処理に関わる分野で導入されています。 今日はnginxの性能の比較よりもサーバーの開発者(nginx module)もしくはサーバーの運営者としてのnginxにある仕組の中で一つを紹介したいと存じます。 サーバーの開発や運営をする場合ロジックや設定などの変更により配布の後、サーバーを再起動することがあります。 その再起動の時にウェブサービスとしてリクエストの処理を続けなが
KLab Advent Calendar 2011 「DSAS for Social を支える技術」の8日目です。 前回は php のプロセス数を絞ることのメリットを解説しました。 プロセス数を絞るには FPM を使うなどの方法もありますが、 DSAS for Social では php は Apache + mod_php を使っていて、 それにリバースプロキシを組み合わせて利用しています。 今日はこのリバースプロキシの役割を説明して行きます。 以降、リバースプロキシのことを単にプロキシと呼びます。 プロキシを使う理由 そもそも、なぜプロキシを使うのかを説明しておきます。 5秒ルール ケータイ向けのソーシャルアプリでは、ユーザーからのリクエストは 一旦プラットフォームのサーバーを経由して、アプリを提供している Webサーバーに到達します。 このとき、アプリ側のレスポンスがあまりに遅いとプ
この記事は http://atnd.org/events/21910 のために書かれたものです。 一つ前の5日目は @sora_h さんの钱柜娱乐_钱柜娱乐平台_钱柜娱乐777(唯一)官方网站でした。明日は、 @master_q さんの予定です。 nginx の内部の仕組みやモジュールの作り方について簡単に紹介してみます。 最近 nginx のコードを読んでハックを試みました。 nginx のコードについてはほとんどドキュメントがなく、日本語でも見かけなかったため（もし書いている人がいたらすみません）、後から続く人にとって多少でも参考になれるようメモをまとめました。（2011/12/06 デバッグについて少し追記） 全部読みきったわけではないので、コードを読む上でのとりかかりぐらいの情報です。もし、間違いがあれば教えてください。 このメモは stable version である Nginx
Av-Jyo.com Related Searches: 5 Best Auto Insurance for Seniors Top 5 Medicare Advantage Plans Low Cost Car Insurance for Seniors Apply for Housing Housing Programs for Seniors
最近、め組ことデジタルキューブさんと、一緒に仕事をやらせてもらってます。 今の所は、主に WordPress サイトの高速化とかやってるんですけど、その中で WordPress サイトを複数台のサーバで負荷分散させて高速化させる案件があったので、その時の作業内容をシェア。 最近はさくらの VPS とか、低価格の VPS が出てきてるので、個人でも手を出せる領域かもしれませんね。 今回は2台のサーバを使って PHP の処理を負荷分散しました。 構成は、こんな感じです。 プライマリサーバ ( vps1.example.com : 192.168.0.1 ) Nginx, Load Balancer、PHP FastCGI のアプリケーションサーバ lsyncd (リアルタイム rsync を実現するためのサービス) セカンダリサーバ ( vps2.example.com : 192.168.0
Home > PHP | Web+DB > nginx+php-fpmをyumでインストールして、WordPress/CakePHPを動かす設定 www.1×1.jpの環境をApache+mod_phpな環境から、nginx+php-fpmな環境へ移行しました。 さくらVPSのCentOS5.5環境にnginx+php-fpmをyumでインストールして、CakePHPとWordPressを動かす設定を行いました。 このエントリでは導入ということで、インストールから、とりあえず動作するところまでをご紹介します。 0. 構成 nginx+php-fpm環境にCakePHPとWordPressをインストールします。 それぞれ以下のURLでアクセスできるようにします。 http://www.1×1.jp/ -> CakePHP http://www.1×1.jp/blog/ -> WordPres
beta の invite もらったので DotCloud で遊んでみました。 dotCloud - One home for all your apps アプリ1つくらい設置してみないとなんだかよくわからないよねってことで、とりあえずどこで公開するかなーと思っていた、paste アプリ を設置してみた。 Pastit: http://www.pastit.dotcloud.com/ Pastit GitHub: https://github.com/sotarok/pastit/ DotCloud の PHP の環境は、Ubuntu 上の nginx + php5-fpm (PHP 5.3.2) が標準で、なんというか時代の流れを感じました。いいね！ のは、まあいいとして、まぁ PHP アプリなんてものはたいてい Apache で動くことが前提とされてるもので (そうなのか? いや、そう
※この記事はnginxの現時点での最新stable 0.8.54を使っています。 2回目の投稿になります、sugyanです こんにちは。 最近、jsdo.itでちょっとしたAPIを作ってみているのですが、連続で大量のリクエストが来るのはちょっと困るので、防御策としてnginxのリクエスト制御モジュール"HttpLimitReqModule"を導入してみることにしました。 http://wiki.nginx.org/HttpLimitReqModule 何も設定しない場合 まずは普通のnginx設定でhttpサーバを立ち上げて、動かしてみます。 worker_processes 1; error_log logs/error.log info; events { worker_connections 256; } http { log_format test '$remote_addr -
15:59 | 先日、運営しているサイトcocoの画像サーバを構築しました。昨今はVPSが500円程度で借りられる様になり、一人WEBサービス屋には本当にいい時代になりました。今回、選定対象にしたのは、以下3つの業者です。ServersMan（初期0円 / 月額490円 / メモリ256M / HDD 10G）S@@Ses（初期3000円 / 月額450円 / メモリ512M / HDD 50G）SAKURA Internet（初期0円 / 月額980円 / メモリ512M / HDD 20G）料金やスペックについて、2010/12/19時点のものを記載しました。キャンペーン適用や保障スペックなど細かい注意点がありますので、詳しくは各社サイトでご確認下さい。シミュレーション処理数値目標は、月間1億アクセスとしました。これは、1ページ当たり50画像掲載だったとすると、200万PV。ブラウザキ
目的 フロントがHTTPリクエストを受けて、バックエンドのアプリケーションサーバにreverse proxyするような構成において、指定秒数以内に何かしらのレスポンスを返したい。 200が返せない場合は、処理を打ち切って500を返したい。 背景 フロントでApacheやNginxをreverse proxyとして使っている場合、バックエンドが無応答になってしまうと、クライアントにレスポンスが返るのはデフォルトで数十〜数百秒後(ApacheのTimeoutのデフォルトは300秒、Nginxのproxy_read_timeoutのデフォルトは60秒)になってしまいます。 通常のWebサービスではこのオーダーのタイムアウトでもいいのかもしれませんが、数秒以内に(エラーでもいいので)レスポンスを返すことが求められる環境も存在します。(最近、特に多いのではないでしょうか:P) もちろんバックエンドが
期せずして久々の更新になってしまった。ブログを書く気がなくなったとかそういうのではなくてただ単に忙しかっただけ。その間、まぁ仕事が予期せぬ方向から炎上してみたり、事故をもらって愛車が全損したり（フロントガラスが全面熱線入りなんていう変なオプションなどを諸々付けていたからお気に入りだったのに）と決して良いことばかりで忙しかったわけではないけどね！ で、今回は node.js のお話。異様な盛り上がりを見せているものの、じゃぁそれっていったい何かというと「JavaScriptを用いたNon-blocking I/O環境」という非常にシンプルなものだ。 その根底には「うまくスケールできること」と「動作が速いこと」という理念が見受けられる。 まず「うまくスケールできること（多量のアクセスを捌けること）」を解決するにあたり、まずはスレッドモデルか、イベントループかという問題があった。そこで auth
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く