Every day people upload more than 350 million photos to Facebook (as of Dec 2012) and view many more in their News Feeds and on their friends’ Timelines. Facebook stores these photos on Haystack machines that are optimized to store photos. But there is also a deep and distributed photo-serving stack with many layers of caches that delivers photos to people so they can view them. We recently publis
3日間で去年一年間分の花粉が悲惨したようです。元気です。 「HTTPコンテンツ圧縮はどのレイヤーで行うのがいいか」で書いたあたりと問題は共通しているのですが、大規模サイトの運用で最近割とボトルネックとなりやすいのはラック-集約スチッチ間のトラフィックです。1台あたりの性能が飛躍的に向上し、画像転送では100Mbps〜300Mbps、それ以上ぐらいは楽に吐き出すようになっているので、ラックスイッチの1Gbpsのuplinkではすぐに詰まってしまいます。この対策として、高トラフィックのサーバを分散配置したり、link aggregationにて2Gbps-4Gbpsに増速したり、あるいは10Gの導入を検討すると思いますが、それには手間もお金もかかるので、まずはトラフィックを減らせないか考えるわけです。 そこで最近、2カ所ほどでとった方法が、フロントのReverse Proxyで短時間、キャッシ
かれこれ一年ほど前に実施した実サービスでの apache のチューニングネタを思い出したように書いています。 以前いた部署では少ないサーバ台数で大量のリクエストを如何に処理しきるかってことに燃えていたので、静的コンテンツなどをブラウザに支障のない範囲で最大限にキャッシュさせ、サーバとネットワークの負荷を最小化させていました。 当時参考にした情報源は以下の３つでした。 どのようなレスポンスヘッダを返しておけばブラウザキャッシュを最大化できるかのテクニックがまとめられています。 ブラウザキャッシュとレスポンスヘッダ - murankの日記 Kazuho@Cybozu Labs: キャッシュの上手な使い方 [Studying HTTP] HTTP Status Code チューニングにおいて重要なのは自分自身での検証。というわけで自前で検証した結果と検証するために用意したプログラムを公開します。
以前にも書きましたが私は某ポータルサイトのシスアド、兼プログラマをしています。月々１億から３億ページビューを裁いていますが、システムの一番大きなコストはトラフィックです。 100MBit専有とまでなると月４０万は軽く行きます。そこでとにかくページビューをあげながらもトラフィックを減らそうと日々努力しています。この記事の目的はハウジングサービスからアマゾンのクラウドフロントに移行した成功例（または失敗例）について書いていきます。 まず、第一回は既存のシステム（静的ファイル用のサーバ）について簡単に説明します。長年、経験を積みながら行った設定です。あくまでも、サーバのスペック、サイトの用途によっても違ってきます。 OS： Gentoo HTTP Server： 最近lighttpdからまたApacheへ ※lighttpdはものすごくライトウェイトだが、バグの対応が遅い、ガンバレMade
SSDによるコンテンツキャッシュ(ソフト編)
日本最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 English versions of some posts on another blog. ZFSにはSSDをキャッシュに使ってランダムリードの性能を稼ぐL2ARCという仕掛けがあります。L2ARCはOpenSolarisでは使えるのですが、Solaris 10ではまだ使えません。10u6 (10/08)で使えるようになると言われていたのが延期されて、今年の10u7 (5/09)で使えるだろうと思っていたのが、また延期されてしまいました。実は10u7に合わせてSSDを購入したのですが、当てが外れてしまいました。 仕方ないのでバージョン2.2から実用可能になったApacheのmod_disk_cacheを使おうかと思ったのですが、これがうまくありませんでした
Being fast doesn't make you scalable. But it does mean you can handle more capacity with your current infrastructure. Take a look at this diagram of request handlers. You can see that it takes 13 request handling threads to process this amount of load. In the next diagram, the requests arrive at the same rate, but in this picture it takes just 200 milliseconds to answer each one. Same load, but on
改めて勉強したかったので、こんなテストしてみました。 Apacheの設定とテスト内容 <VirtualHost *:80> ServerAdmin zigorou@localhost DocumentRoot /home/zigorou/www/cache ServerName cachetest.art-code.org ExpiresDefault "access plus 5 minutes" Alias /test1 /home/zigorou/www/cache/test Alias /test2 /home/zigorou/www/cache/test Alias /test3 /home/zigorou/www/cache/test <Location /test1> FileETag None ExpiresActive Off </Location> <Location
For a couple of months while developing my new web service, I have been wondering what would be the most efficient way of caching small data, such as SQL responses or HTML snippets. I looked at Cache::Cache and memcached, but was not satisfied by their design, since I did not have any plans of scaling-out my service to multiple servers, but wanted to squeeze maximum performance out from a single s
先日、奥さんの要望によりCache::AdaptiveをCGI::Applicationで使いやすくするプラグインを書きました。 現在はversion 0.03でCPANにCGI::Application::Plugin::Cache::Adaptiveとしてアップされています。 Cache::Adaptive自体については、CPANのドキュメントないしは、奥さんの下記の関連エントリをご覧下さい。 負荷に応じてキャッシュを自動調節する Perl モジュール Cache::Adaptive の使い方 Cache::Adaptiveを簡単に使う方法 使い方や実装方法について簡単に説明してみようと思います。 cache_adaptive()による準備 sub setup { my $self = shift; ### snip $self->cache_adaptive({ backend =>
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HTTPリクエストに基づくファイルキャッシュ機構