HonestyWorks TechNote

ソースコードは こちら に公開しています。

概要

データストアのRead/Writeの無料課金枠が結構シビアなのでもはやキャッシュなしではやっていけないと思ったのがこれを作るきっかけでした。（速度的にはデータストアの呼び出しがそんなに遅いとは感じないのであくまで課金対策が主眼です。）

既存のコードにできるだけ手を入れないで実現したかったのでApiProxyを使ってdatastoreのAPI呼び出しをhookし、protocol bufferのrequest,responseをそのままキャシュしてはどうかと思いつきました。

キャッシュ対象とするのはQuery（RunQueryメソッド）でGetはもともと安いので対象外としました。RunQueryメソッドをhookしてキャッシュにデータが存在すればdatastore APIは呼び出さずにキャッシュしたレスポンスを返す、キャッシュにデータが存在しなければそのままAPI呼び出しをしてresponseをキャッシュする、というしくみになっています。
同一カインドのデータがPutまたはDeleteされた場合はキャッシュを無効にするようにカインド毎のResetDateを持って管理しています。

WriteよりReadのほうが圧倒的に多いシステムではキャッシュヒット率が高くなるのでこのしくみは有効かと思います。
逆に同一カインドのエンティティが頻繁に更新されるようなシステムではあまり効果がないかもしれません。

必要なライブラリ

• commons-logging-1.1
• commons-lang-2.4
• gdata-core-1.0

使い方

必要なjarファイルを追加して、web.xmlのfilterChain先頭に以下のフィルター設定を追加するだけです。

    <filter>
        <filter-name>CacheContextFilter</filter-name>
        <filter-class>jp.honestyworks.pbcache.ContextFilter</filter-class>
    </filter>
    <filter-mapping>
        <filter-name>CacheContextFilter</filter-name>
        <url-pattern>/*</url-pattern>
        <dispatcher>REQUEST</dispatcher>
    </filter-mapping>

その他の特徴

• App EngineのMemcache Quota Limit を超えるサイズのデータも問題なくキャッシュされます。(適切なサイズにchunkされて保存します。）
• memcacheだけでなくThreadLocalなコンテキストにもキャッシュを保持します。（Request毎にクリアされます。）
• 上記ローカルキャッシュは使わない設定にすることもできます。
• Production環境でしか有効になりません。

制限

• datastore APIのasyncCallはsyncCallにデグレードします。asyncCallの恩恵を受けているシステムでは使用しないほうが良いかと思います。

本題とは関係ないけど、ktrwjr が便利

テストをするにあたり、slim3に組み込まれているktrwjrを使ってみましたがすごく便利！これは素晴らしいです。

ダウンロード

• http://code.google.com/p/pbcache/downloads/list

オープンソースとしてありますので自己責任でご自由にお使いください。

フィードバック

使っていただけた方は些細な事でもフィードバックいただけると嬉しいです。protocol buffer はあまり詳しくないので探り探りの実装になってます。
フィードバックは私のtwitterまでお寄せください。 (@miztaka)

CodeMirror はブラウザ上でのソースコード編集に便利なjavascriptモジュールです。
なんでもCMS でもテンプレート編集画面に導入しています。
そのときにIEでエラーが出てしまって嵌ったことがあったので記録しておきます。
IEでjavascriptのエラーが出ると追跡が困難で厄介なんですよね。。

今回の原因は、CodeMirrorで編集対象のtextareaタグがpタグの中に入っていたことでした。（なんと単純）
pタグじゃなくてdivタグのなかにtextareaを入れたら、すんなりエラーが無くなりました。
DOMのinnerHTML操作がinlineのコンテナだとIEではエラーになるそうです。

たったこれだけのことで結構はまってしまいました。

概要

なんでもCMS にはこれまで簡易的な画像リサイズモジュールが付いていましたが、もう少しイケてる感じにしようと思い作り直しました。
たとえば、
/files/Sunset.jpg という元画像があったとして、

/icache/w100/files/Sunset.jpg にアクセスすると

こんな感じで幅100pxの画像が表示されたり、

/icache/w200h200bFFFFFF/files/Sunset.jpg のように

余白を指定したカラーで埋めて固定サイズの画像を作れたりします。

一度リサイズした画像はキャッシュされるのでパフォーマンスも問題無いですし、元画像が変更されればキャッシュも更新されるようになっています。

このモジュールはなんでもCMSのモジュールからは完全に独立しているのでいろいろなところに転用できそうです。

仕様

/icache/`パラメータ指定`/`元画像のパス名` というURL形式でアクセスすると指定したパラメータのとおりに加工した画像が表示されます。パラメータの指定方法は

w120
h200
w150h150
w200h200bFFFFFF

のようになります。

• wXXX 幅をpxで指定します。（省略可能）
• hXXX 高さをpxでしていします。（省略可能。幅または高さのどちらかは必須）
• bXXXXXX 余白の色を指定します。これを指定すると幅、高さ固定となります。

リンクの書き方次第で様々な大きさの画像を作り出せるので非常に汎用的で使いやすい仕組みではないかと思います。

最近WebFontというものが流行ってきているらしい。通常のWebサイトでは各端末に入っているフォントをCSSで指定して使っているが、WebFontというのはフォントデータをサーバーから取得して使うしくみなのでユーザーの端末に入っていないフォントでも表示可能、また様々な種類のとても美しいフォントが用意されているといった点が大きな利点となっている。

なんだ素晴らしいじゃないかと手放しで喜びたくなるが「日本語」という壁が問題を少々複雑にしている。
英語のフォントであればキャラクタの種類が少ないのでWebでの配布に何の問題もないのだが日本語はそうはいかない。
キャラクタの種類が比べ物にならないのでフォントデータが巨大になりWebでのリアルタイムな配布に適さないのだ。
そこで日本語のWebFontを提供しているサービスではどこも「フォントのサブセット化」を行なっているようだ。
必要なキャラクターだけを組み込んだ「サブセット」のフォントデータを生成してデータサイズを小さくしようというのである。

今回ソフトバンク・テクノロジーが提供している フォントプラス を試す機会があったので感想を書いてみる。

まず、日本語のWebFontは現在のところ無料で提供されているサービスは存在しないと思われる。（英語であればGoogleWebFontなどがある。）理由はやはり上記の「フォントのサブセット化が必要」な点が大きいのではないかと思う。
フォントプラスではサブセット化の方式やPV数などで料金プランがわかれているようだ。ここではサブセット化の方式に注目してみてみると大きく2つの方式がある。

スマートライセンス

　javascriptでリアルタイムにフォントのサブセットを生成し、フォントプラスのクラウドサーバーからフォントデータを取得する形式。
　設置方法が非常に簡単（scriptタグの追加とフォント指定のみ）だが、WebFontが表示されるまでに1~2秒のタイムラグが発生するという問題がある。
　先にシステムフォントが表示され、1～2秒後にWebFontに切り替わるという見え方になる。
　これはリアルタイムにサブセットを生成しているという仕組み上しょうがない。

バリューライセンス

　事前に必要なフォントのサブセットを生成し、自社のWebサーバーに設置する形で使用する方式。
　フォント表示にタイムラグは発生しないが、CMSなど動的なページには向かない。
　（更新があるたびにサブセットを作り直す必要が出てくる。）

WebFontを使う箇所が固定文字（ex.ページのタイトルなど）であればバリューライセンスで問題ないのだが、動的なページとなるとやはりスマートライセンスでないと運用がしづらい。
しかしスマートライセンスでの見え方はそのままだとタイムラグがあるのでちょっとかっこわるい。
“スマート”に見せるにはエフェクトなどでタイムラグをごまかすような仕組みを検討しなければいけない。

バラ色の世界が広がるかに見えるWebFontであるが、こと日本語圏のWebでは今のところタイトルなどの一部の文字に部分的に使用するといった限定的な使い方が現実的なところだ。ただ、それだけでもこれまでいちいち画像で作っていた文字などをフォントで表示させられるというのはなかなか嬉しいものである。願わくば無料のサービスが登場して欲しいのだが。。

ApacheでPATH_INFO(もしかしたらクエリーも)に%2F(/をURLエンコードしたもの)が入っていると404 Not Foundを返してしまい
意図したとおりに動作しないという現象でちょっと嵌った。

解決方法は非常に簡単で AllowEncodedSlashes パラメータを設定するだけだった。

AllowEncodedSlashes On

デフォルトではOffとなっている。