3000req / sec と戦う - だるろぐ
ざっくり概要 ピークで3000req / sec 毎分コンテンツ更新要求 コンテンツ更新の際は他所からデータをapi経由で受け取る コンテンツ更新にはTheSchwartzを使用 なコンテンツを色々してきたログ。 尚、ここに書く技術は大半が周囲のギークな方々にサポートしてもらったもので、僕自身が何かしたわけではない。残念すぎる。 構成 internet -> www(squid -> apache) -> app(memcached -> app) -> db フロントエンド wwwサーバがapacheとsquidを動かしている。apacheがリクエストを受け、squidのキャッシュが有ればそれを返し、無ければバックエンドのappサーバへproxy。 バックエンド appサーバがmemcachedとアプリを動かしている。 それぞれ冗長化してるけど、リクエスト数の割に台数は少ない。 技術があ
nginx+squidで画像キャッシュサーバーの作り方 - hideden.hatenablog.com
仕事で画像キャッシュサーバーを構築した時のメモ。大規模事例の設定例が検索してもあまり見つからなかったので同じような境遇の誰かの参考になれば。 ピーク時のトラフィックは数Gbps 画像総容量は数十TB バックエンドのstorageが複数種類 規模とアクセス量とアクセスされる画像の種類が多いので、squidでdisk cacheを使用するとCOSS等を使用してもdiskIOで詰まる為、全てon memory cache。cache容量を確保する為に必然的にcacheサーバーの台数も数十台。 1. squidをsibling構成で並列に並べる cache_peer 10.0.1.1 sibling 80 3130 no-query no-digest proxy-only cache_peer 10.0.1.2 sibling 80 3130 no-query no-digest proxy-o
ロングテールな画像配信 その2 - 3,000万の画像を配信するシステム - mixi engineer blog
Squidを検索する度に最初に表示される画像検索の結果に吹き出しそうになる開発部・システム運用グループの長野です。前回のロングテールな画像配信のその2ということで、実際の画像配信システムについて書かせて頂きます。 ■プロフィール画像の配信について 前回紹介しましたが、mixiにおいてプロフィール写真を設定を設定しているユーザ数は全体の約70%、1,000万人の方が設定をされています。現在配信をしているプロフィール画像のサイズは180x180、76x76、40x40と３サイズあり、合計3,000万以上のファイル数になっています。また、もっともよく使われる76x76のサイズ1,000万件において、1日にアクセスされる画像の数は800万ファイル以上、うち97%が30回以下と非常に広範囲に渡ってアクセスされています。そのため大量の画像を配信できる仕組みが必要になります。 ■配信システムの全体像 プ
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Squidのcache_dirの最適化 : blog.nomadscafe.jp
Squidのcache_dirの最適化 かなり古いMLが元なので今も有効かよくわからないのですが、 RE: [SQU] Squid cache_dir size calculation from Wisnu Wijayanta on 2000-10-09 (squid-users) によると、 １）cache_dirのサイズはHDD(パーティション）のサイズの60%以下に Squidのwikiの方にも記述がありますが、swap.stateファイルや一時ファイルの容量、そしてfilesystemのフラグメンテーションを考えて、少なめにしておく方がよいそうです。 ２）最適なL1ディクレクリ数 cache_dirのサブディレクトリ数は、以下の式で求めます。 (((cache-size-KB/avg.-KB)/L2)/L2)*2= L1 dir. L2はデフォルト256になっており、変更は必要なさ
squid2.6のCOSSの話 - 最速配信研究会(@yamaz)
Squid2.6 のCOSSがいい感じという非常に興味深いエントリが出たので,ふれてみたい. 最初にお断りしておくが,実のところ私の中でもCOSS(とその根底にある事実と思想)に関していろいろ納得できないところがあって,十分には咀嚼しきれていない. なので下記の内容は多少眉に唾して読んでもらって,間違っている所などがあれば指摘してもらえるとありがたい. 以前squid vs apacheというエントリでapacheとsquidの比較を行った結果のエントリを書いた. 詳細は上記エントリを読んでもらうとして,結論としてはsquidはapacheと比べて大規模配信には向かないというモノだ. しかしこれは調査自体が3年も前でsquidも2.5の話だったので,もう実情とあってないかもなぁと思っていた.その一方squidも着々と進化をしていたようで,2.6からキャッシュオブジェクトの新しい格納方法であ
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
Poundで作るロードバランサとSSLラッパ
Squidリバースプロキシによるキャッシング オープンソースのプロキシサーバといえば、最初に名前が挙がるのはSquidでしょう。一般的にプロキシと呼んでいる機能とは、厳密には「フォワードプロキシ」（Forward Proxy）と呼びます。今回はSquidをフォワードプロキシとしてではなく、「リバースプロキシ」（Reverse Proxy）サーバとして利用し、そのキャッシュ効果で性能向上を狙います。 リバースプロキシとは Webサーバの前面にSquidリバースプロキシを導入すると、クライアントからのアクセスをWebサーバに代わってSquidが処理することになります。前回、ナローバンドからのアクセスがレスポンス低下の原因になることを説明しました。このナローバンドからのアクセスはSquidが処理する一方、WebサーバとSquidの間は高速に処理されるので、Webサーバがボトルネックになるのを防ぐ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
WIDE University