Dimensional Research が 3,000 人以上のモバイル アプリ ユーザーを対象に実施した調査では、今日の顧客の期待について私たちの多くが信じていることが裏付けられました。
技術専門家として、アプリはパフォーマンスの要素のほんの一部に過ぎないことを理解しているため、これらのパフォーマンス関連の統計はイライラさせられるかもしれません。
applicationのパフォーマンスは向上することがわかっています。 applicationパフォーマンスの測定は、その下にあるすべてのレイヤーのパフォーマンスに依存します。 これは、OSI の全体的な枠組みでは、applicationを構成する実際のコードとデータ以外のすべてを指します。
「スタック」のこの(非常に簡略化された)表現を検討してください。 これらの各レイヤーには、独自のパフォーマンス プロファイルと課題があります。 物理層でもapplicationのパフォーマンスに大きな影響を与える可能性があります。 たとえば、ケーブル モデムの電力低下により、最終的には最下層の信号がデータを転送するため、applicationのパフォーマンスが急激に低下する可能性があります。 信号が劣化した場合、データを再送信する必要がある場合があります。 再送信は、メッセージ全体の転送に時間がかかることを意味します。 これにより、強力で安定した信号に依存するすべてのものが悪影響を受けるため、顧客エクスペリエンスが低下します。
この関係をスタック全体にわたって繰り返すことができます。 ウィンドウ サイズの問題、順序の乱れたパケット、Web サーバーの過負荷などはすべて、「アプリ」の全体的なパフォーマンスに影響を及ぼします。 いずれかのレイヤーのパフォーマンスが最適でない場合は、applicationも同様にパフォーマンスが最適でない可能性があります。 アプリのパフォーマンスは、実際にはその下のレイヤーのすべてのパフォーマンスの合計です。
アプリのパフォーマンスを管理するための最良の選択肢は、常にアプリごとのapplicationサービスです。 アプリごとの(専用の)アプリ サービスを使用することで、それらのサービスをapplicationのニーズに合わせて特別に調整できます。
アプリのパフォーマンスに詳しい人は、一部の TCP 設定は長時間のアプリ セッションに適している一方、他の設定は短時間のバースト的なトランザクションに適していることを知っています。 ネットワーク層の MTU などの小さな要素が、Xbox に 20 GB のゲームをダウンロードするのにかかる時間に大きな影響を与える可能性があります。
applicationのパフォーマンスは多くの要因によって影響を受けます。 組織が最適な顧客体験を求めている場合は、すべてを各applicationに合わせて最適化する必要があります。
これが、パフォーマンス (最適化と高速化) はアプリケーション中心のサービスであると私がこれまで何度も指摘してきた理由です。 これは、負荷分散やアプリ保護などのアプリ高速化サービスが、サービスを提供するアプリとより密接に関連付けられる必要があることを意味します。 不変性、クラウドネイティブ アーキテクチャ、コンテナ、コードとしてのインフラストラクチャの概念に基づく新しいデプロイメント モデルにより、applicationごとに、アプリケーションごとのアクセラレーション、保護、最適化サービスを展開および運用できるようになります。 これは重要なことです。これらのサービスは、モバイル アプリや Web アプリが顧客のパフォーマンスの期待に応えられるようにするのに役立つからです。
しかし、そこで止まるわけにはいきません。
最適な顧客エクスペリエンスの提供も、顧客環境における同じスタックに依存することを忘れてはなりません。 デバイスの機能、接続の強度と速度、システム負荷などがこの変数のスタックに影響を及ぼし、パフォーマンスを低下させる可能性があります。
これが、applicationサービスに可視性が必要な理由の 1 つです。 顧客環境から収集された情報とapplication環境の情報を組み合わせることで、パフォーマンスの問題の原因に関する貴重な洞察が得られます。 これらの環境を調整する機能も、applicationエクスペリエンスに対する顧客の期待を満たす、またはそれを上回るために重要です。
可視性は、組織がapplicationsを保護、拡張、高速化するための重要な要素です。 これらのアプリをコンテナ、クラウド、顧客環境に広く配布するほど、パフォーマンスの低下に直面した際に可視性だけでなくアクションも確保できるapplicationサービスをより広範囲に配布する必要性が高まります。