米Yahoo!、社内で使われているWebプロキシキャッシュ「Traffic Server」をオープンソース化 | gihyo.jp
濃縮還元オレンジニュース 米Yahoo!、社内で使われているWebプロキシキャッシュ「Traffic Server」をオープンソース化 2009年11月4日、米Yahoo!はWebプロキシキャッシュ「Traffic Server」をオープンソースとして公開しました。プロキシキャッシュとは、よくアクセスされるコンテンツをキャッシュして高負荷なHTTPトラフィックを効率良くさばくための技術です。ほかに有名なものでは「Squid」があります。 Traffic ServerはC++で書かれており、コード量は数十万行にも及びます。またマルチスレッドで動作し、一般的なクアッドコアマシンで秒間リクエスト数が3万を超えるなど、非常に高速に動作します。実績も申し分 なく、米Yahoo!のトップページやメール、スポーツ、ニュースなど多くのサービスで使われています。 元をたどると、2002年に米Yahoo!によ
SquidFaq/ConfiguringSquid - Squid Web Proxy Wiki - Can I make Squid proxy only, without caching anything?
🔗 Configuring Squid 🔗 Before you start configuring by Gregori Parker The best all around advice I can give on Squid is to start simple! Once everything works the way you expect, then start tweaking your way into complexity with a means to track the (in)effectiveness of each change you make (and a known good configuration that you can always go back to when you inevitably fubar the thing!). 🔗 Ho
キャッシュサーバ運用技術 Internet Week ‘99 Tutorial @Yokohama 12/16/99 鍋島 公章 NTT 情報流通プラットフォーム研究所
1 (C) nabe@slab.ntt.co.jp Internet Week '99 Tutorial (12/16/99) 1 Internet Week ‘99 Tutorial @Yokohama 12/16/99 NTT nabe@slab.ntt.co.jp (C) nabe@slab.ntt.co.jp Internet Week '99 Tutorial (12/16/99) 2 • • • 2 (C) nabe@slab.ntt.co.jp Internet Week '99 Tutorial (12/16/99) 3 Part 1 (C) nabe@slab.ntt.co.jp Internet Week '99 Tutorial (12/16/99) 4 • – – • Cache WWW Cache WWW LAN WAN LAN WAN 3 (C) nabe@sl
squidでこんなエラーが大量 - 気まぐれSE日記
OS:TruboLinux 10 Server squidはrpm で入ってる奴 TurboLinuxでsquidが走るサーバを何個か用意して、兄弟キャッシュを有効にしたとたん、 squidが重たくなったしまい、しばらく接続不能な状態に陥ってしまった。 原因はなんだろっか？ってことでログを見てみたら、squidのcache.logにこんなのがズラズラ出ていた。 WARNING! Your cache is running out of filedescriptors ... ようは、接続数が多すぎ？でファイルのデスクリプタが足らんということらしい。 調べてみると、squidが使用できるファイルデスクリプタは、 デフォルト値だと、1024ということで、そりゃすぐ無くなるわなぁってところです。 解決方法 ulimit -HSn xxxxxで増やしてやった状態でrpm作る squidの起動スクリ
Kazuho@Cybozu Labs: キャッシュの上手な使い方
« C-0.05 | メイン | cygwin + mod_perl » 2006年02月08日 キャッシュの上手な使い方 キャッシュといっても、ウェブブラウザやウェブプロキシのキャッシュのことです。 ・Internet Explorer のキャッシュの動作 Internet Explorer は、同一ウィンドウ内で複数回同じウェブページを読み込む場合、２回目以降はキャッシュのデータを使用します (デフォルト設定の場合、 Last-Modified または Expires ヘッダがついている場合のみ)。 つまり、同じウィンドウの中で、 ページA を読み、次にページB を読み、そしてページA を再び読み込むようなケースでは、２回目にページ A を表示する際にはキャッシュのデータが使用され、ウェブサーバへの再問い合わせは行われません。 また、 Last-Modified ヘッダと Expire
SquidによるReverse Proxyの構築
Squid2.6STABLE8以降は、"http_port" の "accel" オプションでリバースプロキシ（アクセラレータ）を指定するようになった。 Squid-2.5以前のアクセラレータモードの動作はまったく異なるため、引き続き使用する場合は2.6以降にアップグレードすることを強くお勧めします。 このページでは、リバースプロキシ（Reverse Proxy）を使った、Webサーバのパフォーマンス改善について示します。 このページは次のような章立てになっています。 １章ではリバースプロキシの概要、２章では普通のリバースプロキシと透過モードでのリバースプロキシの比較、３章ではリバースプロキシでのキャッシュの働き、４章ではSquidをリバースプロキシとして機能させる設定 １章、リバースプロキシの概要 ２章、普通のリバースプロキシと透過モードでのリバースプロキシの比較 ３章、リバースプロキシ
Webプロキシ利用率のSquid Graphを用いた確認
Webプロキシとして人気の高いSquidだが、プロキシアクセスおよび転送に関する統計情報をWebページ形式で表示するSquid Graphと組み合わせれば、Squidの設定が最適化されているかが簡単に可視化できる。 Squid Graphは、手元のSquidプロキシサーバのaccess.logファイルに記録されたログを基にして、キャッシュのヒット数やキャッシュのみで処理されたリクエストの比率といった、プロキシアクセスおよび転送に関する統計情報をWebページ形式で表示するためのPerlスクリプトである。こうしたSquid Graphの機能は、Squidの設定が最適化されているかという確認をする際に役立つはずだ。 Squidのキャッシュが有効に機能しているかのそのほかの確認法としては、Simple Network Management Protocol（SNMP）のサポート設定をSquidに施
Squidの更新パターンでインターネットアクセスを高速化する
プロキシキャッシュサーバであるSquidの設定パラメータを用いてバイトヒット率を上げれば、利用可能な帯域幅を3～6割近くも拡大できる。Webサイトの最適化を考えるあなたにはまずこれを試してみていただきたい。 帯域幅の制限は、インターネットに接続している多くの人にとっていまなお残る問題の1つだ。しかし、プロキシキャッシュサーバSquidをネットワークにインストールし、設定パラメータを用いてバイトヒット率を上げれば、利用可能な帯域幅を3～6割近くも拡大できる。 Squidは、きめ細かいチューニングによってさまざまなニーズに対応できる。現行の安定版には少なくとも249個のパラメータがあり、丁寧なコメントがついた設定ファイル（通常は「/etc/squid.conf」）は4600行以上もある。このボリュームには、経験豊かな管理者でも圧倒されるだろう。設定の変更はすべてこのファイル上で行う。 1週間で
squid2.6のCOSSの話(その２) - 最速配信研究会(@yamaz)
squid2.6のCOSSの話の続き COSSのパフォーマンスのよさに関して「俺だまされてない?」というモヤモヤ感が高かったんだけど,あちこちの方々と議論した結果これが正解だろうという結論に行き着いた. ありがとう！＞あちこちの方 友人との会話. yamaz: おっすおっす。いる？ xxxxx: お久しぶりです! yamaz: squid2.6のCOSSって知ってる? xxxxx: 初耳です。＜COSS yamaz: http://blog.nomadscafe.jp/archives/000705.html yamaz: http://wiki.squid-cache.org/SquidFaq/CyclicObjectStorageSystem yamaz: このあたりの話なんだけど、 yamaz: なぜコレが速いかっていう見解って持ってる? xxxxx : 3年ぐらい前、apacheを
squid2.6のCOSSの話 - 最速配信研究会(@yamaz)
Squid2.6 のCOSSがいい感じという非常に興味深いエントリが出たので,ふれてみたい. 最初にお断りしておくが,実のところ私の中でもCOSS(とその根底にある事実と思想)に関していろいろ納得できないところがあって,十分には咀嚼しきれていない. なので下記の内容は多少眉に唾して読んでもらって,間違っている所などがあれば指摘してもらえるとありがたい. 以前squid vs apacheというエントリでapacheとsquidの比較を行った結果のエントリを書いた. 詳細は上記エントリを読んでもらうとして,結論としてはsquidはapacheと比べて大規模配信には向かないというモノだ. しかしこれは調査自体が3年も前でsquidも2.5の話だったので,もう実情とあってないかもなぁと思っていた.その一方squidも着々と進化をしていたようで,2.6からキャッシュオブジェクトの新しい格納方法であ
squid vs apache - 最速配信研究会(@yamaz)
http://blog.livedoor.jp/nipotan/archives/50538571.html を読むとmixiではsquidが一部で使われているようだ.具体的にどこで使われているかはわからないけれど, 当然我々もsquidには目をつけていてapacheのmod_proxyとの比較検討を行ったことがある. その結果squidはスケーラブルな配信サーバを構築するのには向いていないという結論になった. それはこんな理由による. 1. キャッシュされたファイルのインデックスデータとメタ情報をメモリに置くのが無駄 squidはキャッシュされたファイルのインデックスデータとメタ情報をメモリに置く. よって画像が増えれば増えるほどインデックスが大きくなりすぎて,本来使用したい ファイルシステム用のバッファキャッシュが食いつぶされてしまうという結果になった. 実際某サイトでは数十万URL程
ロングテールな画像配信 その2 - 3,000万の画像を配信するシステム - mixi engineer blog
Squidを検索する度に最初に表示される画像検索の結果に吹き出しそうになる開発部・システム運用グループの長野です。前回のロングテールな画像配信のその2ということで、実際の画像配信システムについて書かせて頂きます。 ■プロフィール画像の配信について 前回紹介しましたが、mixiにおいてプロフィール写真を設定を設定しているユーザ数は全体の約70%、1,000万人の方が設定をされています。現在配信をしているプロフィール画像のサイズは180x180、76x76、40x40と３サイズあり、合計3,000万以上のファイル数になっています。また、もっともよく使われる76x76のサイズ1,000万件において、1日にアクセスされる画像の数は800万ファイル以上、うち97%が30回以下と非常に広範囲に渡ってアクセスされています。そのため大量の画像を配信できる仕組みが必要になります。 ■配信システムの全体像 プ
mixi Engineers’ Blog » ロングテールな画像配信 その1
開発部・システム運用グループの長野です。最近は「サーバ／インフラを支える技術」を読みながら通勤しています。今回はmixiの画像配信について書かせて頂きたいと思います。1回目は画像配信の課題について説明させて頂きます。 ■画像配信の種類 これまで画像の配信は大きく分けて2種類あると考え、システムを構築してきました。1つは１ファイルあたりへのアクセスが非常に多くなりますが、ファイル数が少ないもの。もう一つはファイル数が膨大になる代わりに、１つのファイルへのアクセスは少ないものになります。 前者はmixiの中で使われるロゴ画像やメニューの画像等のページ部品、また広告画像や絵文字画像になり、後者はユーザがアップロードする日記やアルバムの画像にあたります。ページの部品の画像はファイル数はそれほど多くないものの、サーバへのアクセス数が最大で秒間に数万リクエストにもなります。逆にアルバムや日記の画像は全
Apache + Squid + Zope - 私の二次記憶
以下、記述に誤りがあるかも知れません。御了承ください。なお、御指摘頂けると幸いです。 Plone の遅さがどうしても気になったので、キャッシュを入れることにしました。しかし、Apache 2.0 の mod_cache は experimental であるということと、thread 付き APR という機能が必要ということで、NetBSD 1.6 で動かすのは怖そうなのでやめました。その代わりに調べていたら、Squid が有用であることが分かりました。SquidGuard と組み合わせる説明は Plone.org にもありますが、凝ったことをしなければ Squid 単体でも問題なさそうです。 階層構造としては、 ブラウザ → Squid （逆プロキシ*1） → Apache → Zope というのが一般的なよう*2ですが、試した感じでは、以下でも大丈夫そうです。 ブラウザ → Apache
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Squidのfiledescriptor増加 : blog.nomadscafe.jp