タグ

poundに関するpoppenのブックマーク (12)

  • pound と apache をバランスよくチューニングする必要性について

    もう二ヶ月ほど前の話なのですが、お仕事でサイトが異常に重い(遅い)んだけど・・・という苦情が月に1〜2件ほどきていたので、重い腰を上げて格的に調査・解析して pound と apache のチューニングを実施しました。チューニング後はサイトが重いという苦情は皆無になりました。(≧∇≦)b 今回のチューニングのキモは pound と apache をバランスよくチューニングするということでした。完全に見落としていた点でもありました。とりあえず苦情がきてた時点までの構成を図にするとこんな感じでした。 何しろ Web サーバの Load Average も CPU 負荷も高くないのでサーバ側は悪くないという思い込みが原因特定を遅らせた一番の原因。この2つの数値はとっても重要なのですが、この数値に真実の見極めを惑わされてはいけません。 以下、調査手順など備忘録的なメモ。途中かなり寄り道したり脱線

  • emmettshear.com

    This domain may be for sale!

  • pound で SSL ラッピング+負荷分散 - Devel::Bayside

    mod_ssl を使うと apache がメモリと CPUいまくり、非常に効率が悪いので、pound を使って SSL ラッピングしてみます。ついでに負荷分散もできて一石二鳥です。 /etc/apache2/ports.conf の編集 Listen 80 -> Listen 8080 /etc/site-available/example の作成 NameVirtualHost *:8080 <VirtualHost *:8080> ServerName example.com DocumentRoot /somewhere/example.com <Directory /> Options Indexes FollowSymLinks AllowOverride FileInfo </Directory> </VirtualHost> <VirtualHost *:8080> S

    pound で SSL ラッピング+負荷分散 - Devel::Bayside
  • Pound が Header Buffer を 2KByte しか確保しない不都合

    業の Web サーバの構成について以前書いた記憶もあるのですが、Lighttpd や Apache2 の mod_proxy が流行る前に構築したこともあって、ちょっとだけ Pound が流行った?時によくある構成で組んでます。ザックリ図にしてみると な感じになっています。で、前から薄々気がついてはいたのですが、この構成、致命的な欠陥があるんです。 その欠陥とは、pound の HTTP リクエストのヘッダ処理の実装にあります。pound のソースは適当にしか読んでいないので、間違ってる可能性もありますが、図にするとヘッダーのサイズ最大値の処理がこんな感じになっています。 ヘッダーの中でサイズが大きいと言えば、Cookie しかないですね。その Cookie に関しては RFC 2109 (set-cookieについて)と RFC 2965 (set-cookie2について)で定められて

  • Output logs to file option for Pound

    poppen
    poppen 2006/07/16
  • 上海虹桥商务区:核心区入驻企业已超三千家,经验将推广全区 新华(吴6日勇兵月1社发摄)-武冈新擞蔬菜行情网

    最新文章 2018-12-26 21:39▪ 佛山:2019年1月1日起购房入户入学并入积分体系 2018-12-26 21:39▪ 温医大大四女生失联2天:自称去买早饭,监控显示最后现海边 2018-12-26 21:39▪ 杨浦3条公交线路拟调整居民以后出行方便了 2018-12-26 21:39▪ “上海新年第一游”相约龙华精彩升级 2018-12-26 21:39▪ 这个公园将是上海市中心最大沿江公园,应勇市长调研,要让市... 2018-12-26 21:39▪ 权健称“百亿保健帝国阴影”文涉诽谤作者:所写均有证据 2018-12-26 21:39▪ “第三届大使图书角”图书捐赠在金边举行 2018-12-26 21:39▪ 互联网企业激活内容价值链体育赛事用户半数为18-30岁... 2018-12-26 21:39▪ 崇明天然气输送再增“大动脉” 2018-12-26 21:

    poppen
    poppen 2006/06/23
  • mizzy.org : mod_rpaf よりも mod_extract_forwarded

    mod_rpaf よりも mod_extract_forwarded Posted by Gosuke Miyashita Wed, 17 May 2006 00:54:26 GMT リバースプロキシな環境では mod_rpaf 使ったりすることが多いと思いますが、バックエンドの apache でアクセス制限かける場合には、mod_extract_forwarded を使ったほうが良いよ、というお話。 バックエンドの apache 2.0 + mod_rpaf な環境で .htaccess によるアクセス制限をかけようとしても、接続元の IP アドレスではなく、pound の IP アドレスで制限がかかってしまう、という現象に悩まされました。で、ソースを眺めてみると mod_rpaf は ap_hook_post_read_request で実行されているのに対し、mod_access は

  • Pound 1.10 へバージョンアップする場合はご注意を!

    仕事で、Pound 1.x 系を使ってます。最近、Pound 1.93 から Pound 1.10 へアップグレードしたらハマりました・・・orz よく、ChangeLog をよんどけっ!って言われればそれまでですが、同じくハマる人って結構いると推測されるので、情報共有ってことで記事にしておきます。 ところで Pound って、変更点がサイトにも情報が記載されてないし、ソースに ChangeLog もないし、README にも書いてないし、*.c のプログラムのヘッダ部分にしか変更点が記載されてないんだよねぇ〜イクナイ! * Revision 1.10 2006/02/01 11:19:54 roseg * Enhancements: * added NoDaemon configuration directive (replaces compile-time switch) * add

    poppen
    poppen 2006/05/08
  • [ロ] ロードバランサ Pound のセッショントラッキング – LOWTECH.NE.JP

    Poundでセッション保持もできるということで、どこまでできるのか調べてみた。 用途としては、osCommerceの改造版であるOpenBazaarをこれまたずいぶん改造した 自製ショッピングカートでの負荷分散を実施したいなぁというのが動機です。 以下の情報を発見 5.1 Can I have session tracking based on URL and/or Cookie? Pound can track sessions based on client IP address, a cookie, an URL parameter or BasicAuthentication. These options are mutually exclusive – only one of them can be used per UrlGroup. クライアントIPアドレスCookie、U

    poppen
    poppen 2006/03/16
  • Pound の SSL セキュリティレベルを制限(上げる)方法

    最近、会社のセキュリティーレベルを上げるべくいろいろな活動がされています。で、最近きたお達しが、Web サーバの SSL の暗号レベルの強化。具体的に言うと、今となっては時代遅れな SSLv2 を許可せず、SSLv3 にすると言うもの。そして、暗号強度の弱い暗号化を許可しないという2点です。 普段、SSL のレベルなんて気にしてネットをやっている方は数少ないと思いますが、IE や FireFox のオプションで指定可能です。例えば、IE だとこんなかんじです。 通常、SSLv2 にチェックがついていると思います。ここで、SSLv2 のチェックを外せば、より暗号強度の強い暗号方式をサーバ側に要求して SSL 通信をすることができます。 クライアント側の設定はこれで完了ですが、サーバ側も当然ながら設定が必要です。 デフォルトの設定(何も設定しない場合)で許可される暗号方式 通常の場合、サーバに

  • Poundで作るロードバランサとSSLラッパ(1/4) ― @IT

    Webサーバの負荷を軽減する方法として、リバースプロキシによる代行とロードバランサによる分散が考えられる。今回は、これらによる負荷の低減方法について解説する。(編集部) Apache自体のチューニングによる性能向上には限界があります。よりパフォーマンスを求めるなら、次にやるべきことはメモリの追加や高性能なCPUへの交換など、ハードウェアの見直しです。しかし、それにも限界があります。 リバースプロキシとロードバランサ ハードウェア単体による性能向上が限界に達した場合は、サーバ構成の見直しを行います。まず考えられるのが、リバースプロキシをWebサーバの前面に立ててクライアントからのアクセスを肩代わりさせる方法です。Webサーバがボトルネックになるのを防ぐとともに、セキュリティ向上にも寄与します。 もう1つの方法は、より高可用性を意図した構成として負荷の分散を図ることです。高可用性とは、サーバの

    Poundで作るロードバランサとSSLラッパ(1/4) ― @IT
    poppen
    poppen 2005/11/09
  • http://www.ramendk.com/hibi/563

  • 1