先日、ある家電大手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 |
＜関連＞
高速化プロジェクト その２
0 件のコメント:
コメントを投稿