CDNとの付き合い方 – cat /dev/random > /dev/null &
最近何かと話題なCDNですが、そもそもCDNってなんだろう・・・どんなことに使えるんだろう？的なことを書いてみようと思います。 一応先に言っておくと、私はCDN業者に所属したことないのであくまでも利用者として見た時の話を書きます。 また、私の考えであり、様々なワークロードがあるなかでこれがすべてではありませんので、こんな考えもあるんだなぁぐらいに思ってもらえると助かります。 そもそもCDNってなんだろうか そもそもCDNはContent Delivery Networkの略であってCache Delivery Networkの略ではありません。 要はコンテンツをクライアントに対して高速・効率的に配信するためのネットワークです。 良くCDNといえばその成り立ちからキャッシュというイメージはありますが、重要な要素の一つではあるもののCDNの全てではありません。 さらに言えばAkamaiのInt
VarnishCache4.0.0が公開されました – cat /dev/random > /dev/null &
今回もgifを撮ってみました。 取得に3秒かかるコードでTTLは10秒です。expire時の動きを見てみてください。 検証コード ■date.php <?php header('Cache-Control: max-age=20'); echo date("Y/m/d H:i:s")."\n"; sleep(3); ■vcl@3.0.5 sub vcl_fetch{ set beresp.do_stream = true; set beresp.ttl = 10s; set beresp.grace = 10m; } ■vcl@4.0.0 sub vcl_backend_response{ set beresp.do_stream = true; set beresp.ttl = 10s; set beresp.grace = 10m; } grace動作 3.0.5 4.0.0 3.0で
CROOZを退職しました – cat /dev/random > /dev/null &
＿人人人人人人人人＿ ＞ 退職しました ＜ ￣^Y^Y^Y^Y^Y^Y^￣ twitter.com/xcir/status/27… — ＼いわなちゃんさん／ (@xcir) December 14, 2012 なんとなく突然の死ジェネレータを使って退職しましたと呟いてみたら ネタと思われたのか、数人の方から「リアルな話ですか？」とリプライが帰って来ましたが本当に退職です。 正確には有給消化中で年内は在籍しています。 僕がクルーズに入社した2009年当時はまだ社名はウェブドゥジャパンでオフィスも麹町で ブログ、携帯公式コンテンツなどが主力コンテンツでしたが 今ではモバゲー向けのソーシャルゲームとコマースを主力でやってます。 いろいろ環境が激動するなかでコードを書くことはもちろん、 ネットワークまで幅広い分野で貴重な経験をさせていただきました。 何やってたの？ ・社内PHPフレームワーク ・画
Varnishのストレージの話 – cat /dev/random > /dev/null &
Varnishは様々なオブジェクトのキャッシュを行いますが その際にオブジェクトの保存を何処に行うかを選択することができます。 現在のバージョンでは malloc file persistent といった3つのストレージが存在しており、それぞれに特徴があります。 今回は特にpersistentに焦点をあてて解説します。 malloc メモリ上にストレージを置いているVarnishで一番高速なストレージです。 メモリ上に置くため当然のことながらサーバの移設での一時停止や再起動、 workerのpanicでの自動再起動などでキャッシュが吹き飛んでしまいます。 file ファイル上にストレージを置く、若干遅いストレージです。 ファイルと名前はついているものの永続化を目的としておらず、 ストレージへの書き込み時にflushしません。 読み書きはページ・バッファキャッシュ、つまりOSに任せており V
Varnish3.0.3が公開されました – cat /dev/random > /dev/null &
Varnish3.0.3が公開されました。 今回の変更は多くのバグフィックスとツール系の機能拡充とドキュメントの整備です。 公式リリースノート varnish-cache-3.0.3 バグフィックス ・ストリーミングと正規表現の評価においてクラッシュの要因となるバグを複数修正しました。 ・ESIとGZIPにおいて壊れたオブジェクトを返却するケースが存在する問題を修正しました。 ・ESIのremoveタグ内にHTMLのコメントがあるケースにおいて不適切な削除を行なっていたのを修正 ・ban lurkerのスリープする条件の変更（回収した際は設定値・回収しなかった場合は1秒） ・多くのクラッシュの要因になるバグの修正 ・その他いろいろ修正 ツール系の機能拡充 varnishstat ・json出力オプションの追加(-j) varnishtest ・resp.bodyでレスポンスボディの評価が可
VarnishでPOST・COOKIE・GETを扱うためのVMODを作ってみた(vmod-parsereq) – cat /dev/random > /dev/null &
この前のエントリでPOSTを扱うVMODを作ってみたというのを上げたのですが あの後、使ってくれた人とかからインタフェース変えるとｲｲﾖｰｲｲﾖｰと言われたので req.http.*に格納するのではなくvmod_curlのように良い感じに使いやすくしてみました。 それだけじゃつまらないということで、おまけでGETとCOOKIEに対応してみました。 今回の特徴は以下です。 ・application/x-www-form-urlencodedとmultipart/form-data両方に対応 ・GET・POST・COOKIEに対応 ・格納されているキーの一覧を取得することができます。 インラインCと併用することですべてのGET・POST・COOKIEのキーに対して特定の値 （攻撃っぽいコードなど）が含まれているかなどのチェックが容易です 使い方はこんな感じです。 たとえばPOSTでhogeとい
VarnishでPOSTデータを扱うためのVMODを作ってみた(vmod-parsepost) – cat /dev/random > /dev/null &
Varnishは基本的にPOSTデータを解釈してなにかしらの処理をすることができません。 そこまで不便はないとは思うのですが、たとえば特定のキーワードがPOSTに入ってたら Varnishではじきたいといったことは普通は出来ません。（インジェクションっぽいクエリとか） そのためVarnishでPOSTを手軽に扱うためのVMODを作ってみました。 以下のような特徴・機能があります。 ・application/x-www-form-urlencodedとmultipart/form-data両方に対応 ・パースした値をreq.http.*に格納する ・指定されたヘッダにパースしていない生データを格納可能 ・multipartのデータはurlencodeして格納 ・multipartの生データは（扱いづらいので）application/x-www-form-urlencodedと同じ形式に直して
夏に出したVarnishCache入門をPDFで公開しました – cat /dev/random > /dev/null &
夏コミで同人誌でだしたVarnishCache入門ですがPDFで公開します。 幾つか公開したかった理由はあったのですが、実際コミケまで足を運んで買っていただいた方にちょっと申し訳ないかなと 電子出版での有料配布も考えていたのですが 64P程度で大げさかなというのと、もう一ヶ月経って3.0.1も出たしいいかなと思い公開します。 内容的には初心者向けとなっていますので、そこまで高度な内容については記述していません。 なお3.0.1が公開されたためページ数が変わらない範囲で、その内容についても一部加筆しています。（fallback directorとか） Varnishを使ってみようと考えている方の参考になればと考えています。 PDFのダウンロード ちなみに、時間と印刷費の関係で書ききれなかった事がたくさんあるのですが(転記されないパラメータやら、varnishtestとか・・・） そういうこと
Varnish Cache3.0.1がリリースされました – cat /dev/random > /dev/null &
Varnish Cache3.0.1が公開されました。 主にバグ修正かとおもいきや嬉しい機能追加もあります。 僕は英語が苦手で書いてる時点で変更の検証が終わってないので 勘違いしている訳があったら教えて下さい・・・ Varnish Cache releases Objects with grace and keep set were mistakenly seen as candidates for the shortlived storage, but would not be cleaned up quickly, something that manifested as if there was a memory leak. This is now fixed. Transientストレージにおいてメモリリークのような現象が起きるバグを修正しました。 この件ですね Varnish3で
smalllightでのエンジンの選択の仕方 (ヒントオプション追加） – cat /dev/random > /dev/null &
small lightシリーズ [1] ライブドアのsmalllightを使って動的に画像をリサイズしてみる [2] いろいろsmalllightを使って動的に画像をリサイズしてみる [3] smalllightでのエンジンの選択の仕方 [4] smalllightでのエンジンの選択の仕方 (ヒントオプション追加） 先日の記事を書いた時点では気づいていなかったのですがsmalllightはJPEGのリサイズを高速化するパラメータがありました。 ヒントオプションというものです。早速再度有効にしてとってみました。 テスト画像 JPEG 6400×4800(17.7MB) -> 640×480 ヒントオプションなし dw=640,dh=480,cw=640,ch=480 ヒントオプションあり dw=640,dh=480,cw=640,ch=480,jpeghint=y imlib2(libjpe
smalllightでのエンジンの選択の仕方 – cat /dev/random > /dev/null &
これだけ見ればimagemagickでもいいじゃん！ということになりますが 速さはどうなのでしょうか？ 1024×768のjpgとpngを480×480に収まるサイズ（dw=480,dh=480,da=l）にリサイズした際のパフォーマンスです （gifはimagemagickを使ってください） ファイルサイズはjpgが202KBでPNGは69.6KBです smalllightはレスポンスヘッダに各処理にかかった時間を出力する機能がありこれを使い測定しました。(以下のような出力) X-SmallLight-Description: transfer=19ms, modify image=35ms (load=21ms, scale=7ms, save=6ms) transferはエンジンによって有意な差異が見られなかったのでmodifyをサマライズしましたｌ． 測定する際は、最初に5回アクセ
ライブドアのsmalllightを使って動的に画像をリサイズしてみる – cat /dev/random > /dev/null &
small lightシリーズ [1] ライブドアのsmalllightを使って動的に画像をリサイズしてみる [2] いろいろsmalllightを使って動的に画像をリサイズしてみる [3] smalllightでのエンジンの選択の仕方 [4] smalllightでのエンジンの選択の仕方 (ヒントオプション追加） 最近、動的に画像をリサイズするのが流行っているようです。 ゆめみラボのmod_ktaiやクックパッドのmod_tofu、livedoorラボEDGEのsmall_lightなどいろいろありますが 今回small_lightを使ってみたので記事を書いてみます。 ついでに速いと噂のlibjpeg-turboも入れてみます。 smalllightとは 公式を見るのが一番早いとは思うので一度見てみてください。（→smalllight） 僕がsmalllightで特にいいなぁと思ったのが
携帯向けアニメーションgifをimagemagickを使ってリサイズする方法(php) – cat /dev/random > /dev/null &
昔やってたブログ（閉鎖）のネタ再利用ですが たまたま検索してみたら動く情報があんまりなかったので再度動作確認して記事にしてみました。 携帯でよくあるアニメーションGIFですがリサイズをを行うにはどうすればいいでしょうか？ 例えば以下のコードの場合はダメです 意図したように動かないコード <?php //元ファイル $src='src.gif'; //書き込みファイル $dest='dest.gif'; $im=new Imagick($src); //サムネ作成 $im->thumbnailImage(40, 0); //書き込み $im->writeImage($dest); $im->destroy(); exit; 静止画のGIFが出来上がります。 そこで画像シーケンスを書き込むwriteImagesを使ってみます $im->writeImages($dest,true); アニメー
Varnish3で多くのオブジェクトを持つサイトを運営するときに注意するべきたった一つのこと(Transient storage) « cat /dev/random > /dev/null &
一回こんなタイトルで書いてみたかったいわなちゃんです。 別にこれだけ注意しとけ！というわけではないのですが、とりわけドハマリしそうでまず注意しておきたいポイントに付いて解説します。 Varnish3の新パラメータに shortlived というモノがあります。 これは指定TTLより短い秒数しかキャッシュしない場合テンポラリストレージ（Transient storage）に保存するというものです。 これはTTLが短い場合このストレージに保存することでパフォーマンスをあげようというものです（多分） パフォーマンスをあげようというものなのでこいつはメモリストレージで確保されます storage.list 200 Storage devices: storage.Transient =★★ malloc ★★ storage.s0 = malloc 問題 以下の設定の時Transientストレージ
Tokyo.vclでVarnishCache3の新機能とVUPの仕方を話してきました – cat /dev/random > /dev/null &
hmskさん主催の第一回のTokyo.vclでVarnishの話をしてきました。 5分～15分の長さでと言われたのでのんびりいっぱい喋れる！ ・・・と思ったら詰め込みすぎて結構早口で聞き取りにくかったかもしれません。 申し訳ないです。 内容はVarnishCache3.0の新機能と2.1/2.0系からVUPするときの変更点についてです。 UST（５分あたりから喋ってます） あといくつか資料で補足したい点がありましたので・・・ 別にESI使わなくてもgzip対応の恩恵は受けられるよ！ おもいっきりESIでgzipサポートとは書いていますが別にESIに限ったことではないのでESIを使わなくてもgzipは使えます。 スライド中には一行でしか書いてないのですが、 今まではVarnishではgzipの処理ができなかったので１つのオブジェクトに対してgzip・圧縮されてないコンテンツを持つ場合 両方を
Varnish2.1.2でESIが使い易くなっていた件について(Varnish2.0.6と比較して） – cat /dev/random > /dev/null &
以前書いた記事（VarnishでESIを使うときの注意するべき点）で Keep-AliveはOFFにするべき ESI使用時はcontent-lengthがブラウザ側に返却されないようなのでOFFはほぼ必須です どうしても使いたい場合はESIを使用するときのみkeep-aliveをOFFに・・・ と 直Varnishはやめた方がいい Keep-aliveをオフにしても特定のクライアント(ab/wgetなど）で接続が維持されて5秒ほど待ってしまうことがあります つまりKeep-Aliveが有効かつcontent-lengthがないときの挙動と同じになります じゃぁどうすればいいか？ 自分はフロントにNginxを置いてそこからVarnishにproxyしています と書きましたがどうやら2.1.X系では改善されたようです ということで比較してみます VCLの設定は両バージョンともこのような感じです
VarnishのESIで擬似的にTTLを指定する方法 – cat /dev/random > /dev/null &
以下の記事でもチラッと書いたのですがVarnishの現バージョンではESIのTTL指定がesi:includeタグからできません VarnishでESIを使うときの注意するべき点 単純に考えるのであればvcl_fetchでそれぞれのURLで指定すればいいとも言えるのですが ESIの利点を多少損なっている感もします （個人的にはデザイナ側がこのパーツは10分キャッシュしてもユーザに影響しないよ！とか設定できるのが利点と思ってる） じゃぁどうすればいいのでしょうか あまりスマートではないですが解決方法があります 例えばdocument root直下にあるhello.htmlを ESIでincludeしたい場合で10秒のTTLを指定する時に <esi:include src="/esi/t/10s/hello.html" /> こんな感じの記述でできるようになります default.vcl ##
VarnishでESIを使うときの注意するべき点 – cat /dev/random > /dev/null &
あんまり話題に上らないで個人的に悔しいVarnishのESI(Edge Side Include)ですが 非常に癖がありますのではまりやすいポイントをとりあえず自分用のメモ程度に 2010/06/23追記:Ver2.1.2では多少注意事項が変わっていますのでこちらも参照ください そもそもESIってなに？ 例えばTwitterのホーム画面で考えてみましょう ページは様々な要素で構成されていますが大きく分けて二つに分かれます 表示される度に更新しなくてはいけないもの（広告・タイムライン） 表示される度に更新しなくてもいいもの（フォロワーなどの数） 別にフォロワー数を表示するためにPHPを動かして、DBかmemcacheにアクセスして整形して・・・ といった処理をしてもいいのですが PVが多いWEBサイトの場合、毎回呼ばれる処理はできるだけしたくありません PHP→memcacheとしても負荷が
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
