leonsboxFor those who are never heard about this project: GoReplay allows you to record and replay your production traffic to development…
Docker(pool)を用いたプレビュー環境を検証する(railsアプリ開発チームの活用例) - Qiita
はじめに この記事ではmook/poolを使ってdockerでプレビュー環境を作ろうという趣旨のものです。 docker周辺では技術開発が盛んで、利用シーンも多岐にわたるようになりました。 プロダクション環境での利用、開発時の開発者の環境統一、テストの実行などと行った具合です。 今回はdockerを用いたプレビュー環境の可能性を検証します。 私は普段railsのアプリケーションを開発しています。 railsアプリ開発だけに注目しても、ユーザーが触れるwebの側面もありますし、APIの提供もあります。 さらには、rails開発者は開発の拠点が地理的に分散しています。 もちろんrails開発者以外にもiPhone/Android開発、デザイナー、ディレクターとチームには様々なメンバーが集まっています。。 docker登場以来、チーム開発でどのように有効利用できるかを模索してきました。 その中で
Nginx + WordPress proxy cache篇 - サーバーワークスエンジニアブログ
こんにちは。CSチームの坂本です。 今回はNginxのproxy cacheを利用してWordPressを高速化したいと思います。 いままでの記事 Nginx + WordPress Nginx + WordPress 「Gzip Precompression」モジュール篇 ※EC2の環境、Nginx以外のMySQL、PHP、PHP-FPMの設定などは前回、前々回と同様です。 目次 前回までの構成 今回の構成 設定ファイル（nginx.conf） 設定ファイル（default.conf） 比較 1. 前回までの構成 前回までの構成は以下の図のようなイメージです。 2. 今回の構成 今回は、Nginxをリバースプロキシとしてフロントエンドに追加します。 Nginxをリバースプロキシとして追加し、proxy cacheの設定をおこなうことで、以下の図のような仕組みに変わります。 キャッシュがな
WebSocket アプリの負荷分散 : DSAS開発者の部屋
最近 SPDY と WebSocket がアツいですね。 再来週の SPDY & WS 勉強会 も、定員100名に対して 参加者が 247 名とかなりアツいことになっています。 その予習というわけでもないですが、最近 WebSocket を実サービスへの 導入方法を考えながら遊んでいたので、 WebSocket の負荷分散方法について 考えていることを書いておこうと思います。 ステートフルな WebSocket アプリケーション HTTP サービスは基本的にステートレスな実装になっており、リクエストが来るたびに DBサーバーや memcached などのバックエンドから情報を取得して返していました。 この構成では Web アプリ自体は完全にステートレス化することができているので、 負荷分散機はラウンドロビン等のアプリケーションを無視した負荷分散をすることができました。 しかし、 WebSo
米dotCloud、WebSocket対応のHTTPプロキシ「Hipache」をリリース | OSDN Magazine
アプリケーションプラットフォームサービスを提供する米dotCloudは8月6日、分散HTTPプロキシ「Hipache」をオープンソースで公開した。WebSocketプロトコルに対応し、リッチかつリアルタイムなWebアプリケーションの開発・運用を支援するという。 dotCloudはPlatform as a Service（PaaS）事業を行う企業。さまざまな言語、ソフトウェアスタックに対応するプラットフォームを提供している。 近年、Webアプリケーションにおけるクライアントサーバー間の通信手段としてWebSocketプロトコルが注目されているが、近年Webアプリケーションで多く使われているnginxやHAProxyなどのツールはWebSockectに対応していない。その問題を解決するために開発されたのがHipacheとなる。HipacheはdotCloud社内のネットワークルーティングイン
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
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という変数
WebSocket(node + socket.io)をstunnel + HAProxyでプロキシする - その１ - HAProxyのインストールまで - hrendohの日記
WebSocketのステータスは、昨年12月にRFC6455としてproposed standard（標準化への提唱）のステータスになりました。 node.js+socket.ioやjetty(Java)を始めサーバーサイドの実装は既に多くあり、クライアントはGoogle ChromeとSafariが実装しています。 FireFoxなどはMozWebSocketとして実装されており、リリースは標準化を待っている状態です。 2月にリリースされたFireFox 11より、proposed standardへの移行を受けてWebSocketを正式にリリースしました。 https://dev.mozilla.jp/2012/02/firefox11/ 例えば、サーバーにnode.jsを利用するアプリケーションを構築していく場合、実際にはnode.js自体をスケールしたり、WebSocket以外の機
WebSocket(node + socket.io)をstunnel + HAProxyでプロキシする - その2 - HAProxyの設定 - hrendohの日記
Nginxとnode.jsをHAProxy+stunnelでまとめる方法についてまとめています。 サーバーの構成は以下のようになります。 前回の記事はHAProxyのインストールまで紹介しました。 http://d.hatena.ne.jp/hrendoh/20120328/1332917793 今回は、HAProxyでNginxとnode.jsのサーバーに振り分ける設定方法と、各種パラメータについて実際の設定例を基にまとめてみます。 設定のリファレンスは、公式サイトのDocumentページにリンクがあるテキストのものと、Google codeにも同じ内容のものがまとまっています。 http://haproxy.1wt.eu/download/1.4/doc/configuration.txt http://code.google.com/p/haproxy-docs/ Google co
NginxをリバースプロキシとしてTomcatのレスポンスをGzip圧縮する | DevelopersIO
Nginxをリバースプロキシとして使う Nginxは軽量＆高速に動くWebサーバーです。前回インストールと表示まで実験しました。今回はNginxをリバースプロキシとして動作させて、既存のWebサーバの動作を高速化させます。 はじめまして、Nginx Tomcatのセットアップ アプリケーションサーバ兼WebサーバとしてTomcatをインストールします。 $ sudo brew install tomcat 以上です。 Nginxをリバースプロキシとして使う NginxはWebサーバとして使う事もできますが、既に使い慣れたApacheやTomcatからコンテンツを移動するのは面倒です。逆に、ApacheやTomcatでサイトが運営中の場合、複雑な設定ファイルを修正するのは面倒です。そこで、既存のWebサーバに触らず動作を変えます。 Nginxの動作を設定するファイルは、nginx.confで
[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)
lua-nginx-module の紹介 ならびに Nginx+Lua+Redisによる動的なリバースプロキシの実装案 - hibomaの日記
Nginxは非常に強力なhttpdですが、独自のモジュールを実装しようとするとこれまた非常に敷居が高い印象です。 追記 この記事よりも前に http://openresty.org/#DynamicRoutingBasedOnRedis でほとんど同じ内容のエントリが書かれていました。こちらも参照ください モジュールの開発はむずかしい まず開発用のドキュメントはほとんどありません。必然 既存のモジュールをお手本としますが、コメントも少ないのでソースだけが頼りです。 {ファイル,ネットワーク} I/O を伴う処理では、Nginxのノンブロッキング/イベントドリブンのアーキテクチャにのっとってコールバックを駆使したCで実装する必要があり、LLで育ったゆとり脳では太刀打ちできませんでした lua-nginx-module が代わりになるかも なんらかのNginxモジュールを開発しなければならない
フロントエンドの開発効率が3倍に…！？デバッギングプロキシCharlesの使い方 :: 5509
タイトルは釣りかとおもいきや僕は普通にあるのとないのとで3倍くらい差があるので、界王拳アプリのひとつです。特にWebアプリとか大きめの規模のサイト開発でとても役に立ちます。 Charles こんなことができます（目次） いちいちサーバーへファイル転送なんかしてられない Charlesのインストールとライセンス Map Local（指定URLのリクエストをローカルへ向ける Map Remote（指定URLのリクエストを別のURLへ向ける 常にキャッシュをオフに Locations 設定の流れ（ほとんど全部共通） Throttling で回線速度をシミュレート リクエストが丸裸 例えばXMLHTTPRequestの場合 ログの設定はRecording Settingsから 紹介してる以外にも Reverse Proxy を設定できたり、 Break Points で指定リクエストのパラメータを
nginx で lighttpd のようにユーザーをトラッキングする方法 - unknownplace.org
lighttpd では mod_fastcgi や mod_proxy 経由でアプリケーションが、 X-Lighttpd-Hogehoge: foobar のような X-Lighttpd- ではじまるヘッダーを返してもそれをクライアントに送り返さないという仕組みがあり、 たとえばそれを利用してアプリからユーザーIDを返してあげたりすると、それをクライアントに送ることなく lighttpd のアクセスログにだけ記録する、といったようなことが出来て便利なのですが、 同じようなことを nginx でやりたかったのでしらべてみた。 アプリから X-MyApp-User: foobar みたいなのを返してそれをクライアントに送ることなくアクセスログに記録したい場合、まずクライアントに送らないように、 proxy_hide_header X-MyApp-User; とし、さらに accesslog の
node.jsつかいました - KAYAC engineers' blog
こん＊＊は、taiyohです。 さて、先日のsugyanのエントリ「node.jsはじめました」にて 本日2/25(金) 20:00から行われる、弊社のオンライン説明会もリアルタイム技術を駆使しています！ 新卒採用企画 オンライン会社説明会 2012 | 面白法人カヤック ぜひ見に来てみて下さい！ とありましたが、この説明会で僕はnode.jsを使ったリアルタイムシステムを担当し、説明会の盛り上げに携わっていました。 【何がリアルタイムか】 このイベントでは、講演をustreamにて配信しました。この時、閲覧者はこちらが用意したいくつかのアクションを実行することができます。この情報は自前のストリーミングサーバを経由し、同じようにページを閲覧している別の閲覧者のflashで表示されます。弊社デザイナの林（@barimi）の登場時、スゴイ数のアクションが送信され、かなりわいわいやっていた様子が
HTTPコンテンツ圧縮はどのレイヤーで行うのがいいか - blog.nomadscafe.jp
Reverse ProxyとApplication Serverの2段構成でWebサービスを運用している場合、mod_deflateなどのHTTPコンテンツ圧縮をどちらでやるのがいいのだろうか 少し考えてみると、Reverse Proxyで一括してコンテンツ圧縮する場合は、圧縮に関する設定を1カ所でまとめられるという利点がある、ただし、Reverse ProxyとApplication Serverとの間は未圧縮で流れるため、この間で通信量が多くなる。 逆にApplication Serverでも圧縮した場合は、圧縮の設定を両方のサーバに書く必要があるが、サーバ間での通信量は減らすことができる。 おそらくWebサービスの規模が小さいうちは、サーバ間での通信量が気になることはないので前者の設定を一カ所にまとめるほうがよく、Application Serverの台数が10台〜20台程度になって
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - hipache/hipache: Hipache: a distributed HTTP and websocket proxy
GitHub - corsis/PortFusion: Haskell-powered cross-platform transport-layer distributed reverse / forward proxy & tunneling solution – currently available for all TCP protocols (RDP, VNC, HTTP(S), SSH, ...).
GitHub - substack/bouncy: bounce HTTP requests around for load balancing or as an HTTP host router
GitHub - mikeal/couchcache: CouchCache is a finely tuned caching HTTP proxy for CouchDB written in node.js