カラーひよこ愛好会は移転しました。 このエントリは下記のURLで参照可能です。 http://kuwatan.jp/20070513.html 今後ともカラーひよこ愛好会をよろしくお願いします。
カラーひよこ愛好会(2007-05-13) Squidのログのお話（実践編）
カラーひよこ愛好会は移転しました。 このエントリは下記のURLで参照可能です。 http://kuwatan.jp/20070513.html 今後ともカラーひよこ愛好会をよろしくお願いします。
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からキャッシュオブジェクトの新しい格納方法であ
SquidFaq/CyclicObjectStorageSystem - Squid Web Proxy Wiki
What is COSS? COSS is a Cyclic Object storage system originally designed by Eric Stern. COSS works with a single file, and each stripe is a fixed size an in a fixed position in the file. The stripe size is a compile-time option. As objects are written to a COSS stripe, their place is pre-reserved and data is copied into a memory copy of the stripe. Because of this, the object size must be known be
Squid2.6 のCOSSがいい感じ : blog.nomadscafe.jp
Squid2.6 のCOSSがいい感じ Squidの比較的新しいcache_dirのCOSSが結構いい感じに動いている。 COSSだと、cache objectが１つの大きなファイルに納められるので、ディスクIOがかなり改善しています。 あまり情報がないのですが、Wikiに設定の説明と、aufsとの比較とかがあります。 cache_dir coss /var/spool/squid/coss 30000 block-size=2048 max-size=500000 cache_swap_log /var/spool/squid/%s こんな感じの設定のサーバで、cache個数 50万ファイル以上、最大リクエスト数500req/sec以上、Hit rateが99%の状態において、CPU負荷がUser:数%、iowait:1%弱とかで推移。もうちょっとcache個数の多いサーバでもiowai
squid vs apache - 最速配信研究会(@yamaz)
http://blog.livedoor.jp/nipotan/archives/50538571.html を読むとmixiではsquidが一部で使われているようだ.具体的にどこで使われているかはわからないけれど, 当然我々もsquidには目をつけていてapacheのmod_proxyとの比較検討を行ったことがある. その結果squidはスケーラブルな配信サーバを構築するのには向いていないという結論になった. それはこんな理由による. 1. キャッシュされたファイルのインデックスデータとメタ情報をメモリに置くのが無駄 squidはキャッシュされたファイルのインデックスデータとメタ情報をメモリに置く. よって画像が増えれば増えるほどインデックスが大きくなりすぎて,本来使用したい ファイルシステム用のバッファキャッシュが食いつぶされてしまうという結果になった. 実際某サイトでは数十万URL程
BKCon 2006 - にぽたん研究所
昨日は BKCon 2006 に行ってきた。 BK というのは「一般的にはバッドノウハウの事」なんですが、昨日のは、BKCon と言っても、かつて開催された Bad Knowhow Conference 2004 の続編とかではなく、"B"atara "K"esuma "Con"ference 2006 です。 ※正しくは横浜 Linux ユーザグループ主催の「第 65 回カーネル読書会」のテーマ "mixi.jp: Scaling Out With Open Source" です。 ちなみに、Batara Kesuma さんというのは、株式会社ミクシィの取締役。 mixi の裏側を見せますというか、ちょっと hip な言いかたをすれば "Inside mixi's backend" ってカンジです。 とりあえず、プレゼン内容は YAPC::Asia の時と大凡同じでしたが、プレゼンの持ち
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.squid-cache.org/Doc/FAQ/FAQ-22.html
Amazon.co.jp: Squid: プロキシサーバの設定と運用: 長岡秀行: 本