3000req / sec と戦う - だるろぐ
ざっくり概要 ピークで3000req / sec 毎分コンテンツ更新要求 コンテンツ更新の際は他所からデータをapi経由で受け取る コンテンツ更新にはTheSchwartzを使用 なコンテンツを色々してきたログ。 尚、ここに書く技術は大半が周囲のギークな方々にサポートしてもらったもので、僕自身が何かしたわけではない。残念すぎる。 構成 internet -> www(squid -> apache) -> app(memcached -> app) -> db フロントエンド wwwサーバがapacheとsquidを動かしている。apacheがリクエストを受け、squidのキャッシュが有ればそれを返し、無ければバックエンドのappサーバへproxy。 バックエンド appサーバがmemcachedとアプリを動かしている。 それぞれ冗長化してるけど、リクエスト数の割に台数は少ない。 技術があ
ロングテールな画像配信 その2 - 3,000万の画像を配信するシステム - mixi engineer blog
Squidを検索する度に最初に表示される画像検索の結果に吹き出しそうになる開発部・システム運用グループの長野です。前回のロングテールな画像配信のその2ということで、実際の画像配信システムについて書かせて頂きます。 ■プロフィール画像の配信について 前回紹介しましたが、mixiにおいてプロフィール写真を設定を設定しているユーザ数は全体の約70%、1,000万人の方が設定をされています。現在配信をしているプロフィール画像のサイズは180x180、76x76、40x40と３サイズあり、合計3,000万以上のファイル数になっています。また、もっともよく使われる76x76のサイズ1,000万件において、1日にアクセスされる画像の数は800万ファイル以上、うち97%が30回以下と非常に広範囲に渡ってアクセスされています。そのため大量の画像を配信できる仕組みが必要になります。 ■配信システムの全体像 プ
squidで多段リバースプロキシー - 吾輩のメモである
いわゆるproxyはやったことがあるんですが、reverseはApacheとかPoundみたいなお手軽なやつでしかやったことなかったので、squidでreverse proxy(キャッシュサーバ)です。 構成は proxy (carp1, carp2にリクエストを送るバランサー用ホスト) carp1 (ファイルをキャッシュするホストその1) carp2 (ファイルをキャッシュするホストその2) origin (ファイルをストアしているホスト) となっております。 ホスト名アドレス proxy192.168.0.200 carp1192.168.0.201 carp2192.168.0.202 origin192.168.0.203 proxyはキャッシュをさせずにcarp1, carp2にリクエストをふります。squidではCARP(Cache Array Routing Protocol
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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SSD+Squidで画像をキャッシュしなイカ？
