【本日の嵌り】 Outputstreamをメモリにキャッシュ

　今作成しているWebアプリは画像生成処理の際に一時保管用としてテンポラリファイルに出力している。それがセキュリティ対策のためファイルへの書き出しが禁止されてしまった。さあ、どうしよう。
　幸い画像のファイルサイズも小さく出力後は消しても構わないのでメモリをテンポラリファイル代わりにして書き出せばよさそうである。そこで以下のようなOutputstreamをメモリにキャッシュするものを作成した。画像作成時にファイル名の代わりにキーを指定して書き出して出力時にキーを元に読み出せばよい。サーブレットなどマルチスレッドに対応するには、ファイル名にスレッド番号をつけてやればよい。

これで解決。

【Reflex】 なぜAkamaiと組んだのか

非常に単純な理由である。
　
　Reflex iTextはデータとテンプレートを与えることでPDFを生成する。PDF生成処理は重くサーバリソースを圧迫するため、クラウド・コンピューティング・サービスを利用するのは理にかなっているからだ。
　
　また、AkamaiがGoogleやAmazonなどと異なるのはネットワークのクラウドであるということ。特にAmazonは日本にサーバを置いていないためレイテンシーが問題となる。Akamaiであれば心配する必要がない。

「インターネット・エッジに置いたサーバー群でクラウドを加速化」、アカマイがアライアンスを設立

　「クラウド・コンピューティング・サービスを提供する他の企業は、データ・センター内の設備のスケール・アウトを進めている。ところが、インターネット側のスケール・アウトを実施する企業はあまりない。アカマイはそこを狙っていく。グーグルやアマゾンのクラウドを巨大な発電所に例えると、送電線と変電所の役割を果たすのがアカマイだ」（アカマイ日本法人の小俣修一社長）

【Reflex】 アカマイ様とのアライアンスとReflex iTextの発表

　アカマイ様と弊社は、Reflex iTextのサービスについてのアライアンスを結び、本日プレスリリースした。

アカマイ、精鋭ソフトウェア開発会社とアライアンスを結成

　また、Reflex iTextのドキュメントを以下にUpしているので興味がある方はぜひ参照してみてください。
Reflex iText Overview

ポイントは、以下の2点です。

１）Akamai様がグローバルに展開した膨大なコンピューティング環境にPDF出力エンジンを分散配置することでシステム負荷軽減を図れる。

２）トランザクションによる従量課金となるため、使った分だけのコストしか発生しない。PDFサーバにかける初期投資を低く抑えることができる。

【JavaScript】 高速化プロジェクト その１

　先日、ある家電大手ECサイトのレスポンスが極端に低下するという事故が起きた。すぐに復旧できなかったところを見ると設計に何らかの問題があったのかもしれない。ECサイトにおけるレスポンス低下は致命的である。また、完成後のプログラムのパフォーマンスチューニングは難しい。サービスインしてから発覚したのでは取り返しがつかなくなることもあるので、設計の段階でよく考える必要がある。

今年の春頃のことだが、あるプロジェクトでJavaScriptのパフォーマンスが極端に遅くなるのを何とかしてほしいという相談を受けた。

　AJAXブーム以降、大規模な業務アプリケーションでもJavaScriptはよく使われるようになってきたが、多用するとパフォーマンス低下の心配が出てくる。これは特にDOM操作の多いアプリで起こりがちである。今回のプロジェクトでも、ベンチマーク結果によるとDOM操作に問題があるアプリであることがわかった。とりあえず、アプリの修正は行わないで以下のような対処療法をやってみた。

１．prototype.jsライブラリ改善

　　　　・HTMLファイル内のparentをいじる参考
　　　　・$()にcacheを持たせる参考
　　　　・prototype.jsファイルのサイズ縮小参考

　初期表示にかかる時間を計ったところ、9秒強（サーバ経由だと17-18秒）　＝＞　書き換え後8秒強（サーバ経由だと16-17秒）

２．変数格納

・for文の.lengthを一旦変数に格納

　　　　　初期表示にかかる時間を計ったところ、変化なし

３．jsファイルの圧縮

・他のjsファイルの圧縮もしてみたが、まったくと言っていいほど変わらなかった。

　対処療法ではまったくといっていいほど効果がなかった。しょうがなく設計からやりなおしてスクラップ＆ビルドすることにした。結果は以下のように、初期ロードで倍のスピードとなり、また瞬時にタブ移動やページ移動ができるようになった。それでも初期ロードに時間がかかっているのは、DOMのリンク生成とサーバにおける検索処理時間が短縮できなかったことが原因である。DOMのリンク生成についてはどうしても時間がかかってしまうが、遅いのは最初だけなのでお客様にはなんとか納得してもらうことができた。
　どのようにしてこれだけの高速化ができたのか、詳細については「高速化プロジェクト　その２」以降で説明したい。

旧アプリ（Core2 2.0GHz、メモリ2GB） 単位ms

	初期ロード	タブ移動	ページ移動
APPL1	17.9	4.1	6.8
APPL2	12.5	4.0	3.8
APPL3	18.8	5.7	6.5
APPL4	11.3	1.4	2.3

新アプリ（Core2 2.0GHz、メモリ2GB） 単位ms

	初期ロード	タブ移動	ページ移動
APPL1	8.9	0.1	0.1
APPL2	6.1	0.1	0.1
APPL3	15.5	0.6	0.1
APPL4	3.1	0.1	0.1

＜関連＞
高速化プロジェクト　その２