タグ

mod_proxy_balancerに関するpoppenのブックマーク (10)

  • Apacheのmod_proxy_balancerを使うときはretryを設定すべき - 射撃しつつ前転

    今作っているサービスは、Apacheのmod_proxy_balancerを使ってロードバランシングしている。しかし、バックエンドのサービスサーバを一旦落としてから復帰させると、コネクションがしばらくつながらないという問題に悩んでいた。1分ぐらい放置するとつながるようになるんだけど、1分は結構長い。 よくわからないのでソースを読んでみたところ、mod_proxy_balancer.cを眺めた感じ、ap_proxy_retry_workerという関数がコネクションの再確立をしているのではないかと思えた。しかし、関数の定義を眺めてみると、現在時刻がエラー発生時刻とworker->retryを足した数字よりも大きければworkerのstatusからPROXY_WORKER_IN_ERRORのビットを下ろしているだけで、コネクションの確立がどうのこうのなんて関数はまったく呼ばれてない。ここでなにが

    Apacheのmod_proxy_balancerを使うときはretryを設定すべき - 射撃しつつ前転
  • 負荷分散講習会 Apache編 | feedforce Engineers' blog

    ゴール 負荷分散のいくつかの方法に関して理解する mod_proxy_balancerによる負荷分散クラスタが構築できる 基礎知識編 基的な資料 主にクラスタによる負荷分散の資料。 - Apache モジュール mod_proxy_balancer - mod_proxy_balancerで中?大規模サーバー運用するときの勘所 - cyano あと社外秘資料。 負荷分散? 複数台のサーバにアクセスを分散して、個々のサーバにかかる負荷を減らし、全体的に処理できるアクセスを増やすこと。 以下のようなアプローチがある。 DNSラウンドロビン DNSでひとつのホスト名に複数のIPアドレスを割り当てる方法 シンプル しかしダウンしているホストにもアクセスが振り分けされてしまう 冗長化と併用でなんとかなるかな? 機能ごとにホストを分割 ウェブサーバとDBサーバの分割(基過ぎるが一応これも負荷分散)

    負荷分散講習会 Apache編 | feedforce Engineers' blog
  • ヽ( ・∀・)ノくまくまー(2007-06-05)

    ● 1. 一戸建てタイプ そのアプリ用に専用のマシンを準備できるケース。例えば、アクセス数が少ないβリリース時などは mongrel を直接80ポートで運用することもあるだろう。そして、負荷の増加、またはマルチコアを活かすという次の段階で、cluster 化した mongrel を扱う必要に迫られた場合、このタイプになる。この場合、フロントの仕事はバック(Rails)への割り振りだけだが、そのためにわざわざ Apache2 を持ち出すのは仰々しいと感じるかもしれない。そんな人にお奨めしたいのが Pound サーバだ。いきなり Apache から話が逸れてしまうが、このケースだとリアルでお奨めである。 Pound + mongrel Pound はリバースプロキシ用のWebサーバであり、特化しているだけあって、必要最低限かつ直感的で簡単な設定で済むため、敷居が低いのが魅力だ。それでいて、デジ

    poppen
    poppen 2007/06/06
    mod_proxy_balancer と Rails との連携まとめ
  • Load Balancer ManagerにアクセスするPerl Module : blog.nomadscafe.jp

    Load Balancer ManagerにアクセスするPerl Module mod_proxy_balancerのLoad Balancer ManagerにアクセスするPerl Moduleなんかも作っていたりするので、簡略版を載せてみる。 my $manager = BalancerManager->new( manager => 'http://proxy/lbman', balancer => 'test', # balancer://testの設定 ); $manager->enable('http://foo:8000'); #balancermanagerに登録してあるuri $manager->disable('http://foo:8000'); enable/disableの戻り値は画面のまんまで、Ok or Dis or Err。 該当しない場合は、「-」になる。

  • Ywcafe.net

    Ywcafe.net This Page Is Under Construction - Coming Soon! Why am I seeing this 'Under Construction' page? Related Searches: Healthy Weight Loss Best Penny Stocks Cheap Air Tickets Credit Card Application Top Smart Phones Trademark Free Notice Review our Privacy Policy Service Agreement Legal Notice Privacy Policy|Do Not Sell or Share My Personal Information

  • Server - mod_proxy_balancerを使ったロードバランシング(格闘編) | 海は海、風は風 dozo.rgr.jp

    前回の記事 mod_proxy_balancerを使ったロードバランシング(導入編) で導入はあっさり出来たことをお伝えした。 (ノ・・)ン。。。。。。(((●コロコロッ しかし、世の中そうは甘くないのだよ。 http://hoge.com/webapp みたいな感じでサブディレクトリ風に使うのであれば、 特別トラブルは起きない。 だが、どうしても http://hoge.com をロードバランシングしたいのだ。 これは変えられない。 すると途端にあちこちのものが動かなくなっていく。 ちなみに設定はこう。 ProxyRequests Off ProxyPass / balancer://cluster/ lbmethod=byrequests timeout=1 <Proxy balancer://cluster/> BalancerMember http://xx.xx.xx.xx lo

  • cyano: mod_proxy_balancerで中〜大規模サーバー運用するときの勘所 - (1) mod_proxy_balancerの設定編

    mod_proxy_balancerで中〜大規模サーバー運用するときの勘所 - (1) mod_proxy_balancerの設定編 Apache2.2から、ロードバランシングをしてくれるmod_proxy_balancer というモジュールが標準添付になりました。 このモジュール、その名前の通り、ApacheレベルでHTTPリクエストをバックエンドのサーバーに振り分けることでロードバランシングをしてくれるモジュールです。 Apacheの公式ドキュメントや試しに入れてみた人のBlogなどは散見されますが、実際の現場で運用している事例というのはまだ無いようです。 そこで、実際にピーク時にover 500 request/secでmod_proxy_balancerなサーバーを運用している経験をふまえ、つまずいた点などを公開していきたいと思います。 まず、mod_proxy_balancerの

  • cyano: mod_proxy_balancerで中〜大規模サーバー運用するときの勘所 - (4) mod_deflateと組み合わせる際の注意点編

    mod_proxy_balancerで中〜大規模サーバー運用するときの勘所 - (4) mod_deflateと組み合わせる際の注意点編 Apache2.2から、ロードバランシングをしてくれるmod_proxy_balancer というモジュールが標準添付になりました。 このモジュール、その名前の通り、ApacheレベルでHTTPリクエストをバックエンドのサーバーに振り分けることでロードバランシングをしてくれるモジュールです。 Apacheの公式ドキュメントや試しに入れてみた人のBlogなどは散見されますが、実際の現場で運用している事例というのはまだ無いようです。 そこで、実際にピーク時にover 500 request/secでmod_proxy_balancerなサーバーを運用している経験をふまえ、つまずいた点などを公開していきたいと思います。 今回は、mod_deflateと組み合わ

  • cyano

    ユーザーがページをロード開始してから閲覧できるようになるまでのロード時間はユーザーが自分のページを快適に閲覧できているかどうかを示す重要なファクターです。Google Analyticsのイベントという機能を使用することで、ユーザーの実際の体感速度を可視化することができます。 たとえば、このブログのある期間における体感速度のグラフはGoogle Analytics上で以下のように出ています。 44.84%のユーザーは100〜499msでロードできており、1秒未満でロード完了しているユーザーは合わせて73.49%であるとわかります。また、3秒以上かかっているユーザーも7.42%居ることも分かります。3秒以上ロードにかかるようだと離脱率も高くなるので、7.42%のユーザーに対して何かの施策が必要であるということも分かります。 このように、ユーザーが実際感じている体感速度を可視化することで、この

  • cyano: mod_proxy_balancerで中〜大規模サーバー運用するときの勘所 - (2) ProxyPassディレクティブに渡すパラメーター編

    mod_proxy_balancerで中〜大規模サーバー運用するときの勘所 - (2) ProxyPassディレクティブに渡すパラメーター編 Apache2.2から、ロードバランシングをしてくれるmod_proxy_balancer というモジュールが標準添付になりました。 このモジュール、その名前の通り、ApacheレベルでHTTPリクエストをバックエンドのサーバーに振り分けることでロードバランシングをしてくれるモジュールです。 Apacheの公式ドキュメントや試しに入れてみた人のBlogなどは散見されますが、実際の現場で運用している事例というのはまだ無いようです。 そこで、実際にピーク時にover 500 request/secでmod_proxy_balancerなサーバーを運用している経験をふまえ、つまずいた点などを公開していきたいと思います。 今回は、ProxyPassディレクテ

  • 1