フロント/バックのreverse proxy構成で、指定秒数以内に必ずレスポンスを返す方法 - （ひ）メモ
目的 フロントがHTTPリクエストを受けて、バックエンドのアプリケーションサーバにreverse proxyするような構成において、指定秒数以内に何かしらのレスポンスを返したい。 200が返せない場合は、処理を打ち切って500を返したい。 背景 フロントでApacheやNginxをreverse proxyとして使っている場合、バックエンドが無応答になってしまうと、クライアントにレスポンスが返るのはデフォルトで数十〜数百秒後(ApacheのTimeoutのデフォルトは300秒、Nginxのproxy_read_timeoutのデフォルトは60秒)になってしまいます。 通常のWebサービスではこのオーダーのタイムアウトでもいいのかもしれませんが、数秒以内に(エラーでもいいので)レスポンスを返すことが求められる環境も存在します。(最近、特に多いのではないでしょうか:P) もちろんバックエンドが
記事一覧
URL の重要性は増す一方だ。Web 2.0 と呼ばれる世界、あるいは SemanticWeb においても、URL (URI) それ自身が表す意味というのは重要になってきた。そんな話を前回の本冊子に書いたのだけれども、今回はその実践編である。 Wiki の URL を綺麗に Wiki は相変わらず広く使われている。実際、便利だ。しかし多くの Wiki はURL が美しくない、と思う。これをなんとかしてしまおう。Wiki のコードに手を入れずに済ませるためにまず思いつくのは、mod_rewrite による書きかえだ。mod_rewrite では「ブラウザから置くられてきた URL」を「パス名やURL」に対応付けることができる。 FreeStyle Wiki の場合 FreeStyle Wiki という perl で書かれている Wiki がある。perl で書かれていて、かつ国産のものの中で
mod_rpaf リバースプロキシ経由のリモートホスト上書き
リバースプロキシ経由だと、リモートホストのアドレスがすべてローカル 127.0.0.1 になるので、アクセス解析に意味がなくなってしまう。 プロクシ経由のリクエストに付与されるアドレスを記録した X-Forwarded-For を Host に上書きしてクレルモジュール「mod_rpaf」をインストールして、これに対応。 ■reverse proxy add forward module for Apache (mod_rpaf) http://stderr.net/apache/rpaf/ 上のURLから最新版をダウンロードして展開。 Makefile のAPXS=の行を変更。 APXS=/usr/local/apache/bin/apxs make して インストール。 make rpaf make install ※Apache 2.0 make rpaf-2.0 make inst
Running a Reverse Proxy with Apache:
In 2003, Nick Kew released a new module that complements Apache's mod_proxy and is essential for reverse-proxying. Since then he gets regular questions and requests for help on proxying with Apache. In this article he attempts to give a comprehensive overview of the proxying and mod_proxy_html This article was originally published at ApacheWeek in January 2004, and moved to ApacheTutor with minor
リバースプロキシを導入する際はmod_rpaf
僕の自宅サーバには２つの Apache がインストールされていて、用途により使い分けています。 * Apache 1.3系 + mod_perl → Amazon Search / Google Similar といった高速性を求めるサービス * Apache 2.0系 → その他の静的コンテンツや 通常用途の CGI 等の動的コンテンツ なぜ使い分けるかというと、mod_perl はメモリー喰いなので、静的画像のためにプロセスがもったいない訳です。本当に必要なリクエストにのみ mod_perl をかませば良いですから。 （参考ページ：リバースプロキシ Pound を導入しました。 : NDO::Weblog） で、２つの Apache を透過的に見せてあげるために、リバースプロキシの Pound を使っています。負荷分散も実装できて優れものですが、欠点が一つ。 リクエストをリバースプロキ
lighttpd + FastCGI は mod_perl + Apache1.3 より１割ほど高速 :: Drk7jp
巷で超高速 Web サーバとして話題になっている lighttpd を試してみました。lighttpd に関する日本語ドキュメントは非常に少なく、ちょっと込み入った設定ファイルの記述方法とかの解析に手間取りました。 lighttpd のコンセプトは、「セキュアで省メモリで高速に動作し、柔軟性もある」なのですが、「lighttpd 公式サイトのベンチマーク結果」や「UnknownPlace. - Catalyst ベンチ」で簡単な Catalyst - Hello.cgi のベンチマークが公開されているとおり、Apache 1系、Apache 2系よりも高速に動作するようです。特に static なページの処理は Apache の 2〜3 倍程度は高速に処理できるみたいです。 また注目すべき点として、Apache + mod_perl よりも lighttpd + FastCGI の方が１割
Reverse Proxy と mod_perl の MaxClients - naoyaのはてなダイアリー
NDOメソッドっぽく質問されてたので答えてみる。 あと聞きたいのは(←ずうずうしい…)、アプリケーションサーバとかリバースプロキシサーバとかのapacheなどのMaxClientsをどのくらいにしているのかですね。カリカリにチューニングしているのか、ハイパフォーマンスMySQLでJeremyさんがYahoo! comのことを書いてた様に1台当り MaxClients 30 ぐらいしか立ち上げてないのか。 リバースプロキシはメモリの許すギリギリのラインまで MaxClients を上げて設定してます。スタティックな一定のコンテンツを返すあるいは Rewrite するのが仕事のほとんどなので、CPU パワーや I/O もほとんどかからず、最近のスペックのマシンであればリバースプロキシの性能はメモリ量に完全に依存してる感じです。 ので、MaxClients の数がなるべく稼げるように子プロセスの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
NAKAMURA Minoru's Diary (2007年3月)
技術情報ツリー
Techknow Movable Type: Apache 2.0 mod_proxy によるリバース・プロキシの構築