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
Play2＋nginx/Akka/WebSocketで高速双方向通信
前回の記事「Play2（＋JavaScript）アプリを高速化、最適化する4つのテクニック」では、キャッシュの利用方法や非同期通信を行う手法、クライアントサイドでJavaScriptをうまく扱うテクニックについて紹介しました。 今回はPlay framework 2.x（以下、Play2）を既存のWebサーバーと連携させる方法、並列処理や双方向通信を行う方法を紹介します。 WebサーバーとPlay2の連携 Webサーバーと連携する必要性 連載第2回記事「Play 2.0のアーキテクチャとディレクトリ構成の基礎知識」で解説をしましたが、Play2では「Netty」というHTTPサーバーを内包しており、それを使用してリクエストを処理します。そのため、Play2の起動ポートを80番に設定すれば通常のWebサーバーと同じようにアクセス可能です。 単純なWebアプリケーションの場合はこれで問題はない
WebSocket アプリの負荷分散 : DSAS開発者の部屋
最近 SPDY と WebSocket がアツいですね。 再来週の SPDY & WS 勉強会 も、定員100名に対して 参加者が 247 名とかなりアツいことになっています。 その予習というわけでもないですが、最近 WebSocket を実サービスへの 導入方法を考えながら遊んでいたので、 WebSocket の負荷分散方法について 考えていることを書いておこうと思います。 ステートフルな WebSocket アプリケーション HTTP サービスは基本的にステートレスな実装になっており、リクエストが来るたびに DBサーバーや memcached などのバックエンドから情報を取得して返していました。 この構成では Web アプリ自体は完全にステートレス化することができているので、 負荷分散機はラウンドロビン等のアプリケーションを無視した負荷分散をすることができました。 しかし、 WebSo
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
