ユーザーの作業スピードに追い付けるツールが必要とされています。フロー状態はほんのわずかな待ち時間でも断ち切られることがあります。例えば、Confluence ページの読み込むのに時間がかかってイライラしたことはありませんか? 待ち時間に Facebook をちょっとチェックして (ほんの一瞬!)、ちょっと笑えるハロウィーンのコスチュームを着た猫の写真を数枚眺めた後、今までその存在すら知らなかった Subreddit のページをチェックしている頃には 20 分が経過したことに気付き、それまで何の作業をしていたのか思い出せない状態になっていませんか? とても生産性が高いとは言えません。
今年、私たちが重点的に取り組んでいるものに Confluence パフォーマンス があります。ユーザーが気を散らさずに集中力を保ち、より速く、多くの成果を出せるようにするのが目的です。私たちは数値処理から最も大きな成果を上げられる点を判断し、果敢な目標を立て、その過程で得た改良点を Confluence Cloud カスタマーに展開してきました。ここでは、私たちの成果を紹介し、私たちがパフォーマンス最適化にどのように取り組んできたのかその裏側を説明していきます。
Confluence Cloud が 54% 高速化
1 月に新たにパフォーマンスに重点を置いた取り組みを始めて以来、Confluence Cloud カスタマーに改善されたパフォーマンスを徐々に提供してきました。 そのパフォーマンス強化の積み重ねが顕著なスピード向上につながりました:
- ページ読み込み時間が全体で 54% 減少
- 1 秒未満で読み込まれるページ数が 500% 増加
- 読み込みに 4 秒を超えるページ数が 74% 減少
上記グラフは、Confluence でのページ読み込み時間と 1 月以降のその変化を示しています。この場合、右へ進むほど値が下がるのは良い結果を示しています
。青線は読み込みに最も時間がかかる 90 パーセンタイルに位置するページを示しています。パフォーマンスの多様な側面への私たちの取り組みに合わせて間欠的に成果が出ていることが分かります。赤線はページ読み込み時間の中央値を示しています。劇的な減少は見られませんが、それでも 2 秒を超える値から 1 秒を下回り、大きな減少です。
このパフォーマンス改良を達成した時点ですぐにカスタマーへ提供できるのが Confluence Cloud のすばらしい点です。週ごとのパフォーマンス変化には気付かないかもしれませんが、ここに示されているように長期的には積み重なって大きなパフォーマンス向上となっています。
Confluence のパフォーマンスへの取り組み方法
パフォーマンスは影響を及ぼす要因がとても多く、要因の多くがアプリケーション自体とは別のところにあるので厄介です。アプリケーションのパフォーマンスを測定する標準方法を確立することが第一段階となります。標準を確立したら、パフォーマンス基準値を確立し、将来的なパフォーマンス目標を設定し、その目標へ向けた進展の追跡が可能になります。ありがたいことにこれは新しい課題ではなく、すでにソフトウェアのパフォーマンスを計測するための Apdex (アプリケーション・パフォーマンス・インデックス) と呼ばれる標準指標が確立されています。
Apdex は簡単な計算で、目標設定とパフォーマンスの長期的な追跡に使える 1 つの数値を算出します。Apdex は下記で定義されているように、アプリケーションの応答時間に基づいて各ユーザーインタラクションにポイントを割り当てます:
あるアプリケーション全体の Apdex スコアを出すには、まず、全ページ (または、代表標本) の応答時間を計測し、上記表に従って各ページにポイントを割り当てます。その後、割り当てたすべてのポイントの平均値を算出し、0 から 1 の間の数値を割り出します。それが Apdex スコアです。値が 1 に近いほどパフォーマンスが高いことになります。
Confluence ではカスタマーの全インタラクションの 90% 近くはページ表示です。したがって、私たちは表示ページの読み込み時間に焦点を当てることに決めました。2015 年 1 月の Apdex スコアは約 0.45 でしたので、0.90 への到達を目標としました。これまで 10 カ月間必死に取り組んだ結果、2015 年 10 月時点で Apdex スコアは 0.74 になり目標値まで半分を超えました。
取り組みの一部
トップレベルの指標の確立とパフォーマンス目標の設定はほんの第一歩に過ぎません。次に、設定した目標を達成するためにアプリケーション内で何を変更すべきなのか判断する必要がありました。最も大きな成果が得られる可能性のある場所を見極めるために可能な限り多くの測定を行いました。パフォーマンスが不十分なトランザクションを正確に見極めることができたら、最も大きなパフォーマンス改善を導き出せる項目を優先するバックログを作成することができました。
- ページの読み込みサイズ – 昨年 1 月以来、ページ内の JavaScript と CSS の量を 40% 以上削減しました。JS と CSS のサイズは Confluence でページ読み込みパフォーマンスに最も大きな影響を与えている要因の 1 つです。ブラウザに転送する必要があるコード量を削減することで、ページ読み込みにかかる時間を削減しました。
- マクロ – マクロは Confluence のページの機能性拡張にすばらしい効果を発揮しますが、パフォーマンスのボトルネックにもなりえます。したがって、最もよく使用される Confluence のマクロの一部を実装し直しました。その 1 つが Table of Contents (目次) マクロです。これまで、Table of Contents はサーバーサイドで作成され、ページコンテンツをレンダリングし直す必要がありました。これを JavaScript でクライアントサイドに実装し直すことで最適化しました。
- サーバーサイド キャッシュ – Confluence でのページ表示は多くのデータとサービスに依存しています。パフォーマンス向上のため、私たちはキャッシング機能を多用して Confluence が頻繁に参照する必要があるデータを保存しています。このキャッシュ リフレッシュの方法を検証し直しました。リフレッシュ頻度を最適化し、適切なタイムアウトでデータのバランスを保つようにし、サーバーサイドで使うリソースが多くなり過ぎないようにしました。
ここで説明したのは私たちの考え方と取り組みの表面的なことに過ぎません。データ収集支援とプロセス検証は Brendan McNamara が率いる上級開発チームが行いました。詳細は、developers.atlassian.com で Brendan と彼のチームが投稿する次回のブログシリーズの中でお伝えします。
今後の展開は?
Confluence Cloud カスタマーの皆さんへはここで説明したアップデートはすでに提供済みで、今後も引き続き Confluence のパフォーマンス改良を体験していただけます。そして、Confluence Server ユーザーの皆さんも心配ご無用です: 皆さんへもこの改良をお届けすることになります。次回の Confluence 5.9 でのサーバーパフォーマンスのアップブレードに関しては、また後ほど詳細をお伝えいたします。
私たちはこれまでに達成したパフォーマンス向上を誇りに思っていますが、Apdex 0.90 の目標を達成するため今後さらに努力を重ねていく必要があります。これまでは最も遅いページと最も速いページに主に焦点を当ててきましたので、次はその中間の読み込みに1 ～ 2 秒かかるページに焦点を当てていきます。あらゆる Confluence に関する情報はこのブログストリームに登録するか、Twitter でフォローしてください。
*本ブログは Atlassian Blogs の翻訳です。本文中の日時などは投稿当時のものですのでご了承ください。
*原文 : 2015 年 11 月 2 日投稿 "Confluence performance: twice as fast in the cloud"