Techopediaスタッフ、2016年11月2日
まとめ：ホストのエリック・カバナが、アプリケーションのパフォーマンスと、ロビン・ブロア博士、デズ・ブランフィールド、およびIDERAのビル・エリスと効率を改善する方法について説明します。
あなたは現在ログインしていません。ビデオを見るにはログインまたはサインアップしてください。
エリック・カバナ：ご列席の皆様 、こんにちは。再びHot Technologiesにようこそ。 はい、確かに！ 私の名前はエリック・カバナです。ブリーフィングルームシリーズのcompめ言葉として、この非常に楽しくエキサイティングなシリーズで、今日の別のウェブキャストのホストになります。 タイトルは「アプリケーションアクセラレーション：エンドユーザーのパフォーマンスを高速化する」です。 私があなたのアプリケーションをより速く走らせるのを手伝っているなら、私は仕事の後、バーでビールを買ってくれる男だと思っています。 誰かのアプリケーションに足を踏み入れてスピードアップするには、かなりクールなものにならなければなりません。
本当にあなたのものについてのスライドがあります。Twitter@Eric_Kavanaghで私を見つけてください。 私は常にフォローを試み、あなたが私に言及した場合は常に再ツイートしますので、私に言及してください。
このショーの全体的な目的は、エンタープライズテクノロジーのさまざまな側面に焦点を当て、特定の分野や特定の顔を定義するのに役立つことです。 多くの場合、ベンダーは特定のマーケティング用語を取り上げて、これをどうやってやるか、または他のことについて話します。 このショーは、観客がソフトウェアツールがその分野のリーダーになるために必要なものを理解するのを助けるように本当に設計されました。 この形式は2人のアナリストです。 ベンダーが最初に行くブリーフィングルームとは異なり、それぞれが最初に行きます。 それぞれが、あなたが特定の種類の技術について知るために重要であると考えるものについての見解を与えます。
今日はアプリケーションの高速化について話します。 Dez Blanchfieldからも、Robin Bloor博士からも連絡を取ります。今日、私たちは世界中にいます。そして、ビル・エリスがバージニア州周辺から電話をかけています。 それで、最初のプレゼンターであるDr. Bloorに引き渡します。 ちなみに#podcastのハッシュタグをツイートしたので、気軽にツイートしてください。 奪って
ロビン・ブロア博士：わかりました、その紹介に感謝します。 アプリケーションのパフォーマンスとサービスレベル–これは一種の領域であり、この領域で長年にわたって多くの作業を行ってきました。つまり、実際にパフォーマンスの監視と1つの作業で非常に多くの作業を行ったという意味で方法または別、それらのレベルを試して、計算する方法。 かつて、人々がサイロでシステムを構築したこの時代があったまでは、と言わざるを得ません。 基本的に、システムがサイロ内にある場合にシステムを適切に動作させるために実際に行う必要がある作業量は、考慮しなければならない変数が非常に少ないため、実際にはそれほど難しくありませんでした。 適切にネットワーク化されるとすぐに、インタラクティブでサービス指向が方程式になりました。 少し難しくなりました。 パフォーマンスは一次元にすることができます。 特定のコードパスを繰り返し実行するアプリケーションを考えると、適度に適時にそれを行うことは、1次元のことのように感じます。 サービスレベルについて話し始めるとすぐに、実際にはコンピューターリソースを奪い合う複数のことについて話していることになります。 すぐに多次元になります。 ビジネスプロセスについて話し始めると、ビジネスプロセスを複数のアプリケーションからスレッド化できます。 サービス指向アーキテクチャについて話している場合、特定のアプリケーションが実際に複数のアプリケーションの機能にアクセスしている可能性があります。 それは非常に複雑なものになります。
私が見た–昔、私はこの図を描きました。 この図は少なくとも20年前のものです。 基本的に、IT環境に存在するすべてのものを見る方法であるため、これを「すべての図」と呼びます。 ユーザー、データ、ソフトウェア、ハードウェアの4つだけです。 もちろん、それらは時間とともに変化しますが、実際にこれを見ると、これらの各要素の階層的な爆発があることがわかります。 ハードウェアはい、ハードウェアはサーバーになることができますが、サーバーは複数のCPU、ネットワークテクノロジー、およびメモリで構成される可能性があり、これはたまたま非常に多くのコントローラーです。 実際にこれを見ると、すべてが細分化されています。 変更するデータ、ソフトウェアのパフォーマンスの変更、ハードウェアの変更などのために、それらすべてを調整しようと実際に考えている場合、実際には非常に困難な多変量の状況を見ています。 これが複雑度曲線です。 もちろん、それはほぼすべての複雑さの曲線ですが、コンピューターについて話すときに何度も描かれているのを見てきました。 基本的に、一方の軸にノードを配置し、もう一方の軸に重要な接続を配置すると、複雑な曲線になります。 ノードと接続が何であるかはほとんど関係なく、電話ネットワークのボリュームの増加を表現したい場合は、それが実行されます。
実際、コンピューター環境のノードについて話すとき、あなたはお互いを気にする個々のことについて話しています。 複雑さは、さまざまな構造と従おうとしているさまざまな制約の問題であることが判明しました。 また、数字。 数字が上がると、彼らは夢中になります。 昨日、私は面白いチャットをしました。誰かと話をしていました-彼が誰なのかは言うまでもありませんが、それは重要ではありません-彼らは40, 000のサイトについて話していました。サイト内。 考えてみてください– 40, 000の異なるデータベース。 もちろん、私たちが唯一持っていたものは、明らかに何千ものアプリケーションがありました。 私たちは非常に大規模な組織について話しているのですが、名前を付けることはできません。 実際にそれを見て、実際には、何らかの方法で、複数のユーザーが必要とする複数の異なる期待に応じて適切なサービスレベルを取得しようとしています。 それは複雑な状況であり、私が本当に言っているのはこのことは複雑だということです。 数値は常に増加します。 制約は、ビジネスプロセスとビジネス目標によって決定されます。 あなたは期待の変化に気づくでしょう。
Gmail、Yahooメール、Hotmail、これらすべてのメールシステムが登場するとすぐに、人々は組織内の内部メールシステムが外部の広大なサーバーファームでのこれらの巨大な運用のサービスレベルに値することを期待し始めました組織は、そのようなことをすべて実行するように圧力をかけ始めました。 実際、サービスレベル契約は1つのことですが、期待は別のことであり、組織内で互いに戦うのは厄介なことです。 これがビジネスの視点です。 一部のシステムでは、最適な応答時間は人間の応答時間の10分の1秒です。 10分の1秒は、コブラがあなたを噛むのにかかる時間です。 もしあなたがコブラの前に立っていて、それがあなたに噛むことを決めたなら、遅すぎます、あなたは10分の1秒で応答できないのでそうなります。 10分の1秒は、ボールがピッチャーの手を離れてバットを持った男に届くまでの時間です。 基本的に、彼は投げられたボールを見ると、その時点で正確に反応しなければなりません。 人間の反応、一種の興味深いこと。 ソフトウェアからソフトウェアへの移行は、明らかに高い期待を持つことができます。
次に、私はそれらの市場の状況だと思ういくつかの状況に入ります。そこでは最初にビジネスの価値があります。 これは、特定の株式を株式市場で売却したい場合、おそらくそれよりも少なくなります。たとえば、下落していると思われ、他の多くの人が下落していると思うため、最初に市場に参入した場合に最良の価格を取得します。 広告配信など、非常によく似た状況がたくさんあります。 あなたは、サービスレベルの期待という点でこの動きを持っています。 人間の反応のためのガラスの天井のようなものがあります。 ソフトウェアからソフトウェアに移行した後、この上限の状況に陥った場合、最適なサービスレベルはありません。 誰よりも速いのが最高です。
さて、これは私が行っていた最後のスライドですが、これは組織の要件であるサービスを実際に見てから、複雑さの全体像を示すためのものです。 ここで左側に行くと、システム管理があります。これは、サービスレベルを管理しようとしているサービス管理に役立つソフトウェアのセットです。 その上に、ビジネスパフォーマンス管理があります。 この下のサービス管理自動化領域を見下ろすと、標準化されたサービスに進化する断片化されたサービスがあります。実際にこの種のものに投資したい場合は、統合サービスに進化し、最適化サービスに進化します。 ほとんどの人が行ったことは、これの左下隅のみです。 サービス管理の少しかもしれません。 ビジネスパフォーマンス管理、非常にまれ。 断片化され、ほぼすべて。 完璧な世界がそのグリッドを埋めます。 計装-最適化の問題に言及しました。 システムの一部を最適化できますが、それはシステム全体にとっては良くありません。 心臓を最適にすると、血液が他の臓器に対してあまりに速く循環する可能性があります。 これは、大規模な組織とサービスレベルの問題です。 変数が取得されたばかりであるため、洗練されたツールなしでは何も達成されないことは明らかです。
そうは言っても、私はDezに引き渡します。
Dez Blanchfield：ありがとう、ロビン。 ロビン・ブロア博士のように、私は非常に複雑なシステムのパフォーマンスを非常に大規模に考えることに長年費やしてきました。 おそらくロビンとまったく同じ規模ではありませんが、パフォーマンスは日々のトピックであり、パフォーマンスを求めてすべてを最大限に活用することがDNAの一部です。 実際、私は世界で一番好きなものの1つであるF1カーレースのグラフィックを使用しました。このレースでは、惑星全体がしばらく静止し、車が非常に速く円を描くのを観察します。 すべての側面において、特にパフォーマンスを獲得することに関するフォーミュラIの側面はありません。 彼らはそれがお金の無駄だと思うので、多くの人々はスポーツをうんちします。 週末にサッカーで子供たちを降ろし、他の日に学校に行くために私たちが毎日運転する車は、パフォーマンスベースの開発と研究に由来することがわかります。 それは一種のフォーミュラIカーレースの生活です。 日常の技術、日常の科学は、純粋に高性能に焦点を合わせたもののようなものからしばしば生まれます。
しかし現実には、ロビンが前述したように、継続的なスペースで当然と思われるWebメールやその他のサービスの導入など、100％のアップタイムを必要とする新しい「常にオン」の世界です。私たちの企業および職場環境。 現実には、稼働していても、常にサービスレベル契約を満たしているとは限りません。 この10年間で、アプリケーションのパフォーマンスと可用性のサービスレベル契約を管理する必要性が根本的に変わりました。 もう1つのシステムのパフォーマンスを心配するだけではありません。 世界が少しシンプルになったとき、複数のサービスを実行している単一のサーバーをライブで監視でき、サポートするのが比較的簡単だった場合があります。 私たちができること-そして、ここ数年前、私がシステム管理者だったときに心配していたことはほとんどありません。 たとえば、ターミナルにログインできますか？ オペレーティングシステムは応答しており、コマンドを入力できますか？ アプリケーションは稼働していますか？ ネットワーク全体で物事やI / Oを行う際のプロセスとメモリを確認できますか？ メインフレーム時代には、テープがzip-zip-zipになり、そこから紙が落ちるのが聞こえました。
アプリは応答しており、ログインしてアプリ上で何かを実行できますか？ ユーザーはそれらのサーバーの一部に接続できますか？ それは続きます。 それらはかなり基本的なものです。 次に、いくつか面白いものがあります。ヘルプデスクは緑色ですか。 そうでない場合は、すべてが正常に動作し、誰がドーナツを手に入れるのですか？ 当時の生活は本当にシンプルでした。 当時でさえ、20〜30年前に話をしましたが、その複雑さは依然として非常に高かったです。 比較的簡単な方法で、サービスレベル契約を管理し、パフォーマンスを監視できます。 ロビンが示唆したように、私たちはもう手でそれをすることはできません。 課題は大きすぎます。 事実、少数の優れたアプリ、管理者、システムネットワーク、データベース、管理者がパフォーマンスSLAを監視して満たすことができる時代です。 SLAがなくなってしまったので、昨夜最後のメモをまとめるときに苦労して、非常に複雑なスタックのシステムを最後に見た年を考え、それを理解し、それが何であったかを理解しましたボンネットの下で進行し、私は深い技術的背景から来ています。 現在、管理上、日常的にそれに直面しているのは想像できません。
どうした？ さて、1996年に、データベースドリブンアプリはインターネットブームで変容しました。 私たちの多くはそれを経験してきました。 あなたがインターネットブームの周りにいなかったとしても、あなたは簡単に周りを見回すだけで、日常生活の中で、私たちが今すべてをインターネットに接続していることを認識することができます。 インターネットに接続されたトースターは必要ないので、どうやらWi-Fiに乗るオプションを備えたトースターを手に入れたと思います。 2000年代、特に2000年代初期には、ドットコムブームでサービスパフォーマンスを提供する複雑さのこの大きな成長に対処する必要がありました。 それから、スマートフォンが登場し、今ではアプリケーションが24時間年中無休で常時オンモードになっているWeb 2.0でのとんでもない厄介な火花。
2016年になりましたが、クラウド、ビッグデータ、モビリティという別の泥沼に直面しています。 これらは非常に大きいシステムであるため、理解しやすく、平易な英語で表現することが難しい場合がよくあります。 私たちが話しているいくつかの大きなユニコーンには数万ペタバイトのデータがあるという事実を考えると。 これは、メール、画像、ソーシャルメディアを保持するためのディスクスペースとストレージのフロア全体です。 または、場合によっては、輸送と出荷のロジスティクスでは、すべて銀行業であり、お金の場所、投稿の場所、またはeBayで購入したものの場所です。 私たちが直面しようとしている次の大きな波は、モノのインターネットのこの非常に重い挑戦です。
これで十分でない場合は、人工知能と認知コンピューティングをほぼすべてのものに組み込みます。 最近、SiriとGoogleのエンジンと話をしています。 Amazonが独自のものを持っていることは知っています。 Baiduには、これらのデバイスの1つがあり、通常のシステムに送られるテキストに変換されます。データベースはクエリを実行し、プロセスを元に戻します。 その複雑さについて考えてください。 現実には、今日の標準アプリケーションスタックの複雑さは人間の能力をはるかに超えています。 スマートフォンやタブレットのボタンを押したときに起こるすべてのことを考えると、あなたはそれに話しかけ、それをテキストに変換し、インターネットに至るまでバックエンドシステムに実行し、フロントエンドが受信しますつまり、クエリに変換し、アプリケーションスタックを介してクエリを実行し、データベースを通過し、ディスクにヒットし、戻ってきます。また、中央にキャリアネットワークがあり、ローカルエリアネットワークステータスセンターがあります。 複雑さは怒っています。
これをハイパースケールとして効果的に主張します。 ハイパースケールの複雑さと速度は目を見張るものです。 アプリケーションとデータベースは非常に大きく複雑になっているため、パフォーマンスの管理はそれ自体が科学です。 多くの人がそれをロケット科学と呼んでいます。 オンサイトテクノロジー、オフサイトテクノロジー、さまざまなデータセンターオプションがあります。 物理的および仮想的。 物理サーバーと仮想サーバー、クラウド、サービスとしてのインフラストラクチャ、サービスとしてのプラットフォーム、サービスとしてのソフトウェアは当たり前のことです。 後者のサービスとしてのソフトウェアは、数年前にCFOや組織の一部がクレジットカードを受け取り、自分で物を購入してCIOを回すことができることに気づいたときに怖くなりました。 IT」とCIOは今、これを巻き戻して、制御を取り戻そうとしています。
インフラストラクチャには、ソフトウェア定義のネットワーク、ネットワーク機能の仮想化があり、その下にはおそらく、おそらくマイクロサービスとアクティブなサービスのアプリがあります。 URLをクリックすると、そのURLの最後に、実際に配信するために必要なものを記述する一連のビジネスロジックがあります。 必ずしも事前に構築されたロジックが待機しているわけではありません。 一方で、非常に大規模にスケーリングしている従来のデータベースがあります。 もう1つのスペクトルのHadoopインフラストラクチャとエコシステムは非常に大きいため、私が言ったように、人々は数百ペタバイトのデータについて話しているのです。 持ち運び可能なデバイス、ラップトップ、携帯電話、タブレットまで、複雑なモビリティを実現しています。
Y世代の経験豊富な人々が自分のデバイスを持ち込んでいるため、一部の閉鎖環境でBYODを使用しています。 私たちは彼らにウェブインターフェースについて話させただけです。 インターネットまたはWi-Fiを介して、コーヒーを飲んでいる階下のカフェで無料のWi-Fiを利用できます。 または、内部Wi-Fi。 マシンツーマシンは今や常に存在しています。 これはモノのインターネットの一部ではありませんが、関連しています。 モノのインターネットは複雑でまったく気が遠くなるようなまったく新しいゲームです。 人工知能、そして私たちが話しているすべてのSiriと他の関連デバイスで今遊んでいるものが複雑だと思う場合は、3DであるOlliと呼ばれるものが見える状況になるまで待ってください約6人で市内を走り回ることができる印刷されたバスで、わかりやすい英語を話すことができます。 交通量が増えると、交通量の多いメインエリアで左折または右折することになります。 曲がり、メインロードから左または右に曲がる理由が心配になると、「心配しないで、私は左に曲がります。 前方のトラフィックがあり、私はそれを回避するつもりです。」
そこにあるすべてのシステムのパフォーマンスとすべての複雑さを管理し、そのデータの行き先、データベースに入るかどうか、すべてのインターコネクトとすべての関連するビットを追跡するのは気が遠くなるでしょう。 現実には、今日の速度と規模でパフォーマンスとSLAを管理するにはツールとシステムが必要であり、デフォルトでは、これはツールを用意するのが良いと思う場所ではなくなりました。これは必須条件です。 絶対に必要です。 ちょっとした例として、オープンソースのソフトウェア定義クラウドであるOpenStackの高レベルアプリケーション設計図のリストを紹介します。 これは大きな塊です。 これはサーバーとデータベースだけではありません。 これは、小さな青い塊がそれぞれ物の塊を表す場所です。 場合によっては、ファイルとサーバー、または数百のデータベース、またはもちろん、実行中のアプリケーションロジックの数万個を超えません。 それは小さなバージョンです。 これで生じる複雑さについて考え始めると、本当に気が遠くなるでしょう。 今日では、ビッグデータの分野でも、ブランドだけのスクリーンショットをいくつか掲載します。 ここで管理しなければならないすべての要素について考えるとき、私たちは必ずしも1つのブランドについて話しているのではなく、これらはすべてビッグデータのランドスケープとトップブランドのブランドであり、小さな小さなものやオープンソースだけではありません。 あなたは見て、それはかなり気が遠くなるようなチャートだと思います。
いくつかの業種を見てみましょう。 たとえば、マーケティングを見てみましょう。 以下は同様のグラフですが、マーケティングテクノロジーのみで利用可能なテクノロジースタックからのものです。 これは2011年のグラフです。 こちらが2016年版です。 考えてみてください。これは、マーケティングテクノロジーに関して、テクノロジーのために実行できる製品のブランドの数に過ぎません。 内部のシステムの複雑さではなく、異なるアプリとWeb、開発とネットワーク、その他すべてではありません。 まさにブランド。 5年前の過去があり、今日がここにあります。 悪化するだけです。 私たちは現在、現実にいるこの時点で、すべてのサービスレベル契約を保証することはできません。 十分な詳細、十分な速さ、必要な規模での調査はできません。 監視コンソールが現在どのように見えるかの例を次に示します。 これは、すべての小さなピースを監視する1つの優れた大きな投影スクリーンであるふりをして、20個近くのスクリーンが接着されているようなものです。 ここで興味深いのは、ブランドについては言及しませんが、この監視プラットフォームは、物流および出荷環境で単一のアプリケーションを監視しています。 たった1つのアプリ。 ロビンが現在、実稼働環境で40, 000個のデータベースを持つことができる場所について話していることを考えてみてください。 1つのアプリケーションを監視するこの画面のコレクションの40, 000バージョンを視覚化できますか？ ロビンが言ったように、私は絶対に、適切なツールなしで、適切なサポートなしで、それらのツールを使用したテーブルでのフォークなしで、アプリケーションパフォーマンスは人間にとって失われたゲームであり、ツールとソフトウェアで実行する必要があります。
それで、私はIDERAの友人に引き渡します。
エリック・カバナ：わかった 、ビル。
ビル・エリス：ありがとう。 ここで画面を共有します。 私の画面が見えることを誰かが確認できると思いますか？
ロビン・ブロア博士：ああ。
エリック・カバナウ：大丈夫そうです。
ビル・エリス：ありがとう。 彼が言及したことの1つは、私が本当に待つことができないのは自動運転車でした。 誰も話を聞いていなかったのは、雪が降るとどうなるかということです。 カリフォルニアのエンジニアが、国の他の地域ではかなり雪が降っていることに気づいたのではないかと思います。
Dez Blanchfield：私はそれが好きです、私はそれを覚えています。
エリック・カバナ：典型的な時速1マイル。
ビル・エリス：複雑な環境でのアプリケーションパフォーマンス管理についてお話しします。 私がお話ししたいことの1つは、多くの人がパフォーマンス、反応の性質について話すとき、サーバーの増加、CPUの増加、メモリの増加などです。そのコインのもう1つの側面は処理効率です。 実際、それは同じコインの両面であり、両方を見ていきます。 最終的な目標は、ビジネストランザクションのサービスレベル契約を満たすことです。 最終的に、このテクノロジーはすべてビジネス向けに存在します。 業界初のパフォーマンス管理データベースを持つことについて話しました。 その理想は、パフォーマンスの理想的な型に収まり、アプリケーションのライフサイクルの最初からそれを管理することです。
トピックは本当に4つの部分に要約されます。 1つは、パフォーマンスを管理するプロセスです。 私たちは皆と話しましたが、誰もがツールを持っています。 ツールがない場合、スクリプトまたはコマンドがありますが、欠けているのはコンテキストです。 コンテキストは、アプリケーションスタック全体でドットを単純に接続しています。 これらのアプリケーションは、ブラウザベースです。 これらは、層から層へと非常に緊密に結合されています。 層の相互作用も重要です。 次に、ビジネストランザクションについて説明します。 技術者だけでなく、アプリケーション所有者と運用管理者にも可視性を提供します。
顧客がこれらをどのように使用したかについて、いくつかのケーススタディをご紹介します。 これは、ここでのプレゼンテーションの非常に実用的な部分です。 一般的に何が起こるか見てみましょう。 私は図を描くのが好きです。まるで信じられないほどのテクノロジーのコラージュのようでした。 データセンターのテクノロジーの数は増え続け、成長し、成長しています。 一方、エンドユーザーはそれを気にせず、気づきません。 トランザクションを実行し、利用可能にし、迅速に完了させたいだけです。 通常起こることは、ITの専門家は、エンドユーザーが自己報告するまで、問題が発生したことすら知らないことです。 それは一種の時間のかかる、遅いプロセスを開始し、しばしばイライラさせます。 何が起こるかというと、人々はツールを開き、アプリケーションスタックのサブセットを見ます。 そのサブセットでは、最も単純な質問に答えることが非常に難しくなります。 あなたに問題があるのは普通ですか？ それはどんな取引ですか？ アプリケーションスタックのどこがボトルネックですか？ これらすべての時間を層ごとに見て、これらの質問に答えることができないため、多くの時間とエネルギー、多くのスタッフ、資金、エネルギーを見つけることになります。
これを解決するために、より正確な方法を提供するために、Preciseが実際に行うのは、エンドユーザートラックトランザクションを取得し、それに関するメタデータをキャプチャし、ネットワークを介してWebサーバー、ビジネスロジック層、最終的にすべてのトランザクションが記録システムと対話する多層アプリケーションで、.NETとABAP、PeopleCodeとE-Business Suiteをサポートします。 インベントリルックアップであろうと、レポートに時間がかかっていようと、彼らは常にデータベースと対話します。 データベースは、ビジネスパフォーマンスの基盤になります。 次に、データベースはストレージに依存します。 トランザクションに関するメタデータが応答するもの、誰が、どのトランザクションを、アプリケーションスタックのどこに配置するか、そして何が実行されているかを示すための深いコードレベルの可視性があります。 この情報は継続的にキャプチャされ、パフォーマンス管理データベースに格納されます。これは、誰もが何が起こっているかを見るための1枚の音楽になります。 何が起こっているのかを気にするさまざまな人々や組織があります。技術専門家、アプリケーション所有者、最終的にはビジネスそのものです。 問題が発生すると、そのトランザクションに関する情報を抽出できるようになります。
投資取引を見る前に、それが組織内のさまざまな人々にどのように見えるかを示したいと思います。 管理層では、複数のアプリケーションの概要が必要になる場合があります。 SLAコンプライアンスと可用性によって計算される正常性について知りたい場合があります。 その健康は、すべてが完全に機能していることを意味するものではありません。 この場合、投資取引が警告ステータスにあることがわかります。 さて、もう少し深く、おそらく業務分野で、個々のトランザクションがSLAに違反したとき、トランザクション数などについて追加の詳細が必要になります。運用チームは、ソート。 パフォーマンスアラートが組み込まれています。実際にエンドユーザーのブラウザでパフォーマンスを測定します。 Internet Explorer、Chrome、Firefoxなど、検出することができますが、これは最初の質問に答えます：エンドユーザーに問題がありますか？
飛び込み、それについて他に何を示すことができるか見てみましょう。 パフォーマンスに興味がある人は、Preciseを開きます。 彼らはトランザクションを評価します。 彼らはSLAカラムを見て、SLAに準拠していないトランザクションを特定します。 彼らは、影響を受けたエンドユーザーと、トランザクションがアプリケーション全体に流れたときに何が行われたかを見ることができます。 これらの象形文字を解読する方法は、ブラウザ、URL、UはURLであり、JVMへのエントリポイントです。 この特定のJVMは、Webサーバーから2番目のJVMを呼び出して、SQLステートメントを実行します。 このSQLステートメントが応答時間の72％を占めていたため、これは明らかにデータベースの問題です。 私たちは時間を重視しています。 時間はパフォーマンスの通貨です。 それは、物事の速度が遅いかどうかをエンドユーザーがどのように感じるかであり、リソース消費の尺度です。 それは非常に便利です。 パフォーマンスを評価するために最も重要なのは、一種の単一のメトリックです。 この問題がDBAに引き継がれるのは、単なるデータベースの問題ではなく、このSQLステートメントです。 これは私が話していたコンテキストです。
この情報を入手したので、何が起こったのかを分析することができます。 まず、y軸は1日の時間です。 すみません、y軸は応答時間、x軸は1日の時間です。 データベースの問題があり、2つのオカレンスがあり、そのフローに戻ってそのSQLステートメントを取得し、エキスパートビューに移動します。ここで、Preciseは、何が起こっているのか、そのコントロール、そのコードにかかる時間を表示できます実行します。 データベース層では、実行計画です。 Preciseは、実行時に使用された実際の実行プランを選択したことに注意してください。これは、実行中ではなく、プランが与えられたときの推定プランとは異なります。 データベースが実際に行ったことを反映する場合としない場合があります。
ここに、SQLステートメントの応答時間分析があります。 ストレージに費やされた時間の90％。 CPUで10％が使用されました。 SQLステートメントのテキストと結果レポートを見ることができます。 SQLステートメントのテキストは、実際にはいくつかのコーディングの問題を明らかにし始めています。 セレクトスターです; それはすべての行を返します-失礼、返された行のすべての列。 アプリケーションが必要とするかもしれないし、必要としないかもしれない追加の列を元に戻しています。 これらの列は、処理するスペースとリソースを消費します。 SAPを実行する場合、HANAデータベースは列状であるため、大きな変更の1つは、基本的にSAPを書き換えて、選択スターを選択しないようにし、リソース消費を大幅に削減できることです。 これは基本的に、Java、.NETなど、自社開発のアプリケーションでも多くの時間を要するものです。
この画面では、誰が、何を、いつ、どこで、なぜ表示します。 問題を解決できるSQLステートメントや実行計画のように、その理由がわかります。 Preciseは継続的に実行されるため、SQLステートメントレベルで、トランザクションレベルで前後に実際に測定できるため、問題を解決したことを自分自身で、アプリケーションの所有者および管理を通じて測定できます。 。 そのドキュメントは本当に役立ちます。 このアプリケーションスタックには多くの複雑さがあります。 実際、多くのアプリケーションの中で、私たちが話をしたすべての人が、VMwareでアプリケーションスタックの少なくとも一部を実行しています。 この場合、彼らは顧客サービスアプリケーションを見て、トランザクション時間を見て、それをスローダウンと相関させることが仮想化イベントです。 正確にすべての仮想化イベントを追跡します。 vCenterのプラグインを使用して、それを取得します。
また、競合を検出することもできます。 競合は利用率とは異なります。 顧客サーバーのアプリケーションのコンテキストで、騒々しい隣人がゲストVMに影響を与えている可能性があることを実際に示します。 これで、ドリルインして情報を取得できるようになり、実際には、この場合はCPUリソースを奪い合っている2つのVMを見ることができます。 これにより、スケジュールを確認できるように可視性を持たせることができます。 ゲストVMを別の物理サーバーに配置できます。 あなたが応答する可能性のあるこれらのタイプのすべてのものは、それに加えて、実際にコードの効率を見て、CPUの使用量を減らすことができます。 このプレゼンテーションでは、誰かがCPU消費を何桁も削減できたという良い例があると思います。
それがVMwareでした。 コード自体、つまりアプリケーションコードを見てみましょう。 Java、.NET、ABAPコード、E-Business、PeopleCodeなどで発生していることを正確に表示できます。これらは、この場合はWebLogicへのエントリポイントです。 ここに、調査する必要があるのはこれらのEJBであることがわかり、このシステムでロックが発生していることを示す結果レポートがあります。 繰り返しになりますが、ビジネスロジック層内でドリルダウンして、何が起こっているかを示します。 この場合、特定のインスタンスを見ています。 クラスタリングもサポートしています。 多数のJVMが実行されている場合は、クラスター全体を確認するか、個々のJVM内のボトルネックを確認できます。
あなたがロックに入ると、私は例外に入ることができます。 例外は、パフォーマンスの問題とは少し異なります。 通常、例外は非常に高速に実行されます。 論理エラーがあり、その論理エラーにヒットすると終了するためです。 例外の最盛期にスタックトレースをキャプチャすることができました。これにより、何が起こっているのかを把握しようとしているため、多くの時間を節約できます。 メモリリークもキャプチャできます。 このソリューションにはデータベース層も含まれており、データベースインスタンスを評価することができます。 繰り返しますが、y軸は時間を費やした場所で、x軸は1日の時間です。 システムで何が起こっているのか、私が見ているかもしれないことを自動的に知らせる結果レポートがあります。
Preciseの調査結果レポートに関することの1つは、ログや待機状態だけを調べるのではなく、CPUを含むすべての実行状態を調べ、ストレージから情報を返すことです。 ストレージは、特にソリッドステートの出現により、アプリケーションスタックの非常に重要な部分です。 これらの線に沿って情報を持つことは非常に役立ちます。 特定のストレージユニットでは、個々のデバイスレベルで何が起こっているかを実際にドリルダウンして表示できます。 そのタイプの情報–もう一度、それは深い可視性です。 範囲が広い–アプリケーションパフォーマンスの専門家として活用するのに十分な情報を提供し、エンドツーエンドでアプリケーションを最適化してそれらのビジネストランザクションに対応できるようにします。
あなたと共有したいいくつかのケーススタディがあります。 かなり高速でクルーズします。 私は大丈夫なペースで行くことを願っています。 ストレージについて話すと、時間の経過とともに誰もがハードウェアを変更します。 ハードウェア保証があります。 ベンダーがあなたに言ったことを本当に伝えましたか？ Preciseで評価できます。 あなたが入ってきて、ここで何が起こったのか、彼らは基本的に新しいストレージユニットを入れましたが、ストレージ管理者がストレージユニットレベルだけを見たとき、彼らは多くの競合を見て、この新しいストレージユニットに問題があるかもしれないと考えました。 エンドツーエンドの観点からより多くを見て、実際にどこで起こるかを正確に示します。 実際には、1秒あたり約400メガバイトのスループットから移行しました。この場合、ストレージが応答時間の38％を占めていたため、かなり高いです。 新しいストレージユニットを使用すると、実際にスループットを毎秒600メガバイトに引き上げたため、基本的に2倍になり、トランザクション時間に対するストレージ層の寄与を半分に削減できました。 これを実際にグラフ化することができます。これがカットオーバー期間であり、その後です。
そのため、ハードウェアへの投資に見合う価値があることを証明するドキュメントを再度作成し、その特定のベンダーが期待したとおりに提供しました。 すべてがあります。複雑さ、物事の数、すべての種類があります。 この場合、実際には、誰もがDBAを非難するような状況がありました。DBAは「まあ、それほど速くない」のようでした。ここでは、実際にSAPアプリケーションを見て、このタイプのシナリオはかなり一般的だと思います。 何が起こったのか、彼らはユーザーのためにカスタムトランザクションを開発していました。 ユーザーは、「これは非常に遅い」のようなものです。SAPのプログラミング言語であるABAPコーダーは、「これはデータベースの問題です」と言いました。 彼らはそのエンドユーザーを60秒測定しました。 バックエンドで53秒が費やされました。 彼らはバックエンドを掘り下げ、実際に降順で提示されたSQLステートメントを明らかにすることができました。
リソース消費の25％を占めるこのトップSQLステートメントの平均実行時間は2ミリ秒です。 データベースを非難することはできません。 ねえ、それほど速くない、ね。 問題は、なぜそれほど多くの死刑執行があるのかということです。 まあ、彼らはそれをABAPに戻し、彼は入って、ループのネストを調べ、間違った場所でデータベースを呼び出していたことがわかり、基本的に変更を行い、変更をテストし、新しい応答時間が5秒。 少し遅いですが、彼らはそれで生きることができます。 60秒よりはるかに優れています。 時々、ただフェレットアウトして、それはアプリケーションコードですか、それはデータベースですか、それはストレージですか？ これらは、エンドツーエンドトランザクションのコンテキストを使用することにより、Preciseが機能する領域です。 基本的にこれらのことを終了します。
私はその時を見ていますが、これらのいくつかをさらに進める時間はまだ少しあるようです。 私はこれらを通してストリーミングしています。 このアプリケーションは1年以上開発されていました。 QAに参加したとき、Webサーバーが100％使い果たされており、VMwareでアプリケーションを実行できないように見えました。 誰もが最初に言ったのは、「これを身体に当てる。 実際、Preciseは問題を解決するための追加の方法を提供しました。 トランザクションを確認し、Webサーバー呼び出しを確認しました。これはIIS.NETのASMXとして着信します。 実際に、基礎となるコードが明らかになりました。 私が指しているところにこれが見えますか？ これは23日、11時間です。 うわー、どうしてそれが可能ですか？ 各呼び出しは9.4秒かかり、この呼び出しは215, 000回呼び出されます。 呼び出しごとに、6秒のCPUを使用します。 これが理由です。このコードは、このことを決してスケールできない理由です。 実際、物理的に拡張することはできませんでした。
彼らがやったことは、彼らは開発者に戻り、「誰かが変更を加えることができますか？」と言ったのです。彼らは一種のコンテストを行い、さまざまな提案をテストし、多くを実行できる提案を思いつきましたより効率的に。 新しいものは、CPUの100分の2秒で1秒、2秒弱で完了しました。 現在、これは拡張可能であり、VMwareファームで実行できます。 基本的に、コードレベルとトランザクションレベルの両方で文書化することができました。 これは一種の前であり、その後です。 ここで、Web、.NET、およびデータベースを示すスタックバーグラフに表示されるようになったので、データベースを操作しています。 これは、より正常に実行されていたアプリケーションで見られると予想されるプロファイルです。
わかりました、私はあなたに私があなたに示すことができる追加の点で選んでいます。 多くの人がこれを好むのは、これが多くの店を驚かせているからです。 ビジネスSLAを満たすことができず、誰もが「助けてください」というような場合、このショップでは、午後3時までにビジネスSLAが注文されている状況があり、その日は出荷されています。 彼らが注文を出すことは本当に重要であり、倉庫は非常に忙しいです。 このJD Edwardsの販売注文画面は凍結していたため、これがジャストインタイムの小売在庫管理システムであるという非常に良いアイデアを得ることができます。 空の棚は小売では受け入れられません。 それを売るためにそこに商品を持っているようになりました。 行ったことは、この場合はSQLサーバーデータベースを見ていることです。 外観は、SQL、Oracle、DB2、Sybaseのいずれであっても同じです。
PS_PRODからselectを識別し、期間、それらが非常に実行されるという事実をキャプチャすることができます。 濃い青は、何らかの待機状態、ロギング、ストレージさえも待機していないというキーに一致しました。これはCPUによってバインドされています。 34301までにSQLステートメントを追跡したため、これが実行されるたびに、カウンターをインクリメントして追跡します。 つまり、詳細な履歴があり、その調整ボタンをクリックしてアクセスできます。 これが履歴タブです。 この画面は、平均期間と変化の関係を示しています。 水曜日、木曜日、金曜日、平均期間は約10分の2秒でした。 画面がフリーズすることはほとんどなく、ビジネスSLAを満たすことができます。 2月27日になると、何かが変化し、突然すべての実行時間がここに上がります。実際には、タイムアウトが発生して画面がフリーズするほど遅くなります。 そのSQLが使用されている場合、実行計画やテーブルのインデックスに対する一般的な変更など、詳細な履歴を保持することにより、正確に。 2月27日にアクセス計画が変更されたことがわかりました。 月曜日から金曜日の悪い週。 3月5日、アクセスプランが再び変更されました。 これは良い週です。 このピンクの星は、更新されたボリュームを示しています。
ここでは、基になるテーブルの行数が増加していることがわかります。これは、ビジネスで一般的なことです。 テーブルを成長させたい。 問題は、ステートメントが解析され、SQLステートメントが入力され、オプティマイザーが実行プランが速いときに何をするかを選択し、遅いときに別の実行プランを選択しなければならず、画面がフリーズすることです。 深い技術に基づいて、私は実行計画が何であるかを知る必要があり、Preciseはそれを日付とタイムスタンプで完全にキャプチャします。 これは高速かつ効率的なものであり、これは低速かつ非効率的なものです。 このフィルター結合は、単にこの特定のSQLステートメントを実行するために、より多くのCPUを使用して調整します。 それでも同じ究極の効果がありますが、これは基本的に、結果セットを配信するための低速で効率の悪いレシピを持っています。 だから、私たちはステップスルーします。 ちょっと、もう少し時間がありますか？
エリック・カバナ：ええ、 どうぞ 。
ビル・エリス：わかりました、先に進みます。 ハードウェア、SAP、.NET、JD EdwardsおよびJava-SQL Server環境について話しました。 これがSAPです。ここでは、PeopleSoftを検討しています。 Preciseのサポートマトリックスは広くて深いです。 アプリケーションをお持ちの場合は、おそらくこのレベルの可視性を提供するためにインストルメントできます。 現在起こっている最大の変化の1つは、モビリティです。 PeopleSoftは、Fluid UIにモビリティを導入しました。 Fluid UIはシステムを非常に異なって使用します。 このアプリケーションは進化しています。 Fluid UI –管理の観点からすると、エンドユーザーが自分の電話を使用できるようになり、生産性が大幅に向上します。 数百人、数千人、またはそれ以上の従業員がいる場合、生産性を1〜2％増やすことができれば、給与やその他すべてに大きな影響を与えることができます。 起こったことは、この特定のショップがPeopleSoft Fluid UIを展開したことです。 さて、複雑さについて話すと、これがPeopleSoftスタックです。 1つのアプリケーション、最低6つのテクノロジー、多数のエンドユーザー。 どうやって始めますか？
もう一度、Preciseはこれらのトランザクションを追跡できるようになります。 ここで示しているのは、クライアント、Webサーバー、Java、Tuxedoデータベース、PeopleSoftアプリケーションスタックを示す積み上げ棒グラフです。 緑色はJ2EEにマップされます。これは、WebLogicを言うのにちょっとした言い方です。 これがカットオーバーです。 エンドユーザーはFluid UIの使用を開始し、応答時間は1秒半から2秒、最大で約9秒、10秒になります。 この1つの画面に表示されないのは、「応答しない」人の数です。実際、アプリケーションで画面がフリーズしました。 Preciseがこの顧客に提供できる可視性のいくつかを見てみましょう。
まず、PeopleSoftのトランザクションを見ると、基本的に見ることができます。この種のことは全面的に見ました。 すべてのトランザクションとすべての場所が影響を受けました。 ちなみに、これを見ると、実際に世界中の場所を見ることができます。 アジア太平洋からヨーロッパ、そして北米へ。 パフォーマンスの問題は、特定のトランザクションや特定の地理的な場所にあるのではなく、システム全体にわたるものです。 これは、Fluid UIがグローバルに影響を与えた変更または方法を示す一種の方法です。 ここではスケーラビリティの観点から見ることができます。人々は同じ種類のアクティビティを実行しようとしていますが、応答時間は基本的に低下し、低下しています。 あなたは物事がスケーリングしていないことがわかります。 物事は非常に悪い方向に進んでいます。 ここで、軸数と同時接続を見ると、アクセス数と接続に関して非常に興味深いことがわかります。 ここでは、約5, 000までしかスケールアップしておらず、約100の同時接続を超えています。 これは後に行われます。 これは前です。 したがって、システムに対する私の本当の要求は、このことがスケーリングできる場合、300, 000の範囲です。 昔は、クラシックUIを使用して、30の同時接続を見ていました。
これは、Fluid UIが少なくとも10xの同時接続を使用していることを示しています。 PeopleSoftの内部で発生していることを撤回し始めて、Webサーバーへの影響、SLAが侵害され始めているという事実を確認できるようにします。 すべてを取り上げるわけではありませんが、結局のところ、彼らは基本的にメッセージングに依存しているということです。 それらは基本的にWebLogicであり、Tuxedo内でキューイングを発生させます。 実際、Fluid UIで表示される多層依存関係の問題がありましたが、Preciseは、さまざまなことによって、問題の内容に集中できることを示すことができました。 データベース自体にも問題があったことがわかりました。 実際にはメッセージングログファイルがあり、すべての同時ユーザーのために、そのログファイルはロックされていました。 基本的に、アプリケーションスタック内のすべての層で調整する必要がありました。 複雑さについて話しましょう。実際には、キューイングを示すTuxedo層があり、この層内のパフォーマンスの低下も確認できます。 プロセスを見ることができました。 ドメインとサーバーを確認できました。 Tuxedoでそれを使用するために、通常は、スーパーマーケットのようにキュー、ドメイン、サーバーを追加して輻輳を緩和し、キュー時間を最小限に抑えます。 最後の最後のオプション、Preciseは多くの情報を表示します。
前述したように、すべての重要なトランザクションは記録システムと相互作用します。 データベースへの可視性が最重要です。 Preciseは、データベース内、WebLogic内、Java内、.NET内、ブラウザ内で何が起こっているかを示しますが、Preciseが本当に優れているのはデータベース層です。 これは、競合他社の弱点です。 Preciseを使用してこの問題を解決する方法の1つを紹介します。 データベースの最適化のトライアングルに時間を費やすつもりはありませんが、基本的には、低コスト、低リスク、広範囲、高リスク、高コストのタイプの変更を検討しています。 人々が試して見たい場合は、実際にこのスライドを後でツイートします。 問題をチューニングするための非常に大きなガイドです。 これが、Precise for Oracleのエキスパートビューです。 調査結果レポートの一番上に、60％の影響がこの特定のSQLステートメントです。 このアクティビティ画面を開くと、そこに表示されます。 この選択ステートメントを見ると、実行計画が1つあります。 すべての実行には、2〜48, 000回の実行が必要です。 これにより、さらに48, 000時間の実行が追加されます。
濃い青は、やはりCPUです。 これはCPUに依存しており、待機状態ではなく、ログでもありません。 競合他社の中には、待機状態とログイベントのみを見るものもありますが、一般的に言って、CPUは最も忙しい実行状態であり、最も多くの買い戻しを提供します。 この専門家の視点にたどり着くと、私は非常に迅速に進みます-私がしたことは、テーブル、100, 000行、37, 000ブロックを見たことです。 フルテーブルを実行していますが、このことに関して6つのインデックスがあります。 何が起きてる？ さて、where句を見ると、このwhere句が行っているのは、実際に列を大文字に変換し、大文字に等しい場所を見つけて、変数を見つけることです。 起こっていることは、このことを実行するたびに、Oracleはこの列を大文字に変換する必要があることです。 5万回近く行うよりも、関数ベースのインデックスの大文字でインデックスを作成する方がはるかに効率的であり、Oracleエンタープライズ部門だけでなく標準部門でも使用できます。 それを行うとき、次にできることは、その新しいインデックスユーザーpermを大文字で発行する実行プランを確認することです。
次に、前後の測定から、1秒の実行時間、最大9時間54分、同じ正確なSQLステートメントで集計しますが、そのインデックスは58, 000回の実行に対して大文字で構築されています。時間はサブミリ秒に低下し、合計して最大7秒になります。 基本的に、サーバーで10時間のCPUを節約しました。 これは巨大です。 サーバーを更新する予定がなければ、そのサーバーで生活できるからです。 私は実際にそのサーバーの使用量を20パーセント削減し、実際に前と後を見ることができます。 これが、Preciseが提供できる可視性のタイプです。 私たちが見るかもしれない追加の事柄もいくつかあります、それらが使用されていないのになぜあなたはこれらのインデックスのすべてを持っているのですか？ 彼らはそれをフォローアップできます。 アーキテクチャがあり、時間のトップに到達しているので、それをまとめます。 私はこのソリューションの真の信者であり、私たちはあなたが真の信者になることを望んでいます。 IDERAでは、試用版が顧客を獲得すると信じていますので、興味があれば、サイトで評価を行うことができます。
それで、ビーコンを返します。
エリック・カバナ：ええ、これはあなたがそこに示した途方もない詳細でした。 とても魅力的です。 私は過去にあなたに言及したかもしれないと思う-そして、私はIDERAで行った他のいくつかのウェブキャストで知っている、私はそれを言った-私は実際にIDERAに買収される前からPreciseを追跡してきた2008年、または2009年にさかのぼります。当時はそれに魅了されていました。 アプリケーションの新しいリリースを常に把握するためにどれだけの作業が必要かを知りたいです。 あなたはSAP HANAについて言及しましたが、実際にHANAアーキテクチャを掘り下げ、そこでトラブルシューティングを行うことができるのはかなり印象的だったと思います。 あなたは何人いますか？ あなたの側でどれだけの労力が費やされ、そのどれだけが動的に行われますか。つまり、ツールがデプロイされると、あちこち歩き回り、さまざまなものを見るようになりますか？ 複雑な環境のトラブルシューティングを支援できるように、ツールのどれだけを動的に、ある種、確認できるのでしょうか？
ビル・エリス：あなたはそこで多くの質問をしました。
エリック・カバナ：ごめんなさい。
ビル・エリス：これらのアプリケーションでは、コードを見ると悪魔が詳細にあるため、多くの詳細を提供しました。 実際に実行可能なものを作成するには、そのレベルの詳細が必要です。 実用的な測定基準がなければ、症状について知っているだけです。 実際に問題を解決しているわけではありません。 IDERAは問題を解決することです。 新しいリリースや最新情報を常に把握することは大きな課題です。 それを行うには何が必要なのか、それは本当に製品管理の問題です。 基本的に私たちが物事を最新の状態に保つために、チームに対する可視性はあまりありません。 HANAに関しては、実際にはIDERA製品ラインへの新しい追加です。 それは非常にエキサイティングです。 HANAの1つは、タスクについて少し話しましょう。 タスクでは、SAPショップはレポート目的でデータベースを複製します。 次に、実際に最新のものに人々を調和させる必要があります。 これらの異なるデータベースがあり、それらは異なるレベルで同期していません。 たくさんの時間と労力があり、それに加えてハードウェア、ソフトウェア、そしてそれらすべてを維持する人々がいます。
HANAは、基本的に重複データベースの必要性を回避するために、高度な並列インメモリデータベースを持つという考え方です。 1つのデータベースと1つの真実の情報源があり、常に最新の状態にあります。これにより、すべての調整を行う必要がなくなります。 HANAデータベースのパフォーマンスの重要性は高まります。他のすべてのデータベース、ハードウェア、リソースが購入できる合計の10倍以上の価値があります。 HANAを管理できるようになったことで、コンポーネントは現在ベータテスト中です。まもなくGAに移行する予定です。 IDERAにとっても、基本的にSAPプラットフォームをサポートすることも、これは非常に刺激的です。 私はあなたの質問の他の部分がどのようにショートチェンジしたのかわかりませんが、
エリック・カバナ：いいえ、それはすべて良いことです。 私はあなたに一斉に一斉に投げたので、ごめんなさい。 私はただ魅了されています、本当に、これは非常に単純なアプリケーションではないということですよね？ これらのツールを深く掘り下げ、それらがどのように相互作用しているかを理解していること、そしてあなたの要点で、あなたは頭の中で物語をまとめる必要があります。 実際に何が起こって何が問題を引き起こしているのかを理解するには、情報の断片を組み合わせる必要があります。そうすれば、そこに行ってそれらの問題を解決できます。
ある参加者は、Preciseを実装するのがどれほど難しいかと尋ねています。 別の人が尋ねました。誰が-明らかにDBAです-しかし、これらのツールを使用する組織内の他の役割は誰ですか？
Bill Ellis：正確な展開はもう少し複雑です。 アプリケーション環境についてある程度の知識を持っている必要があります。つまり、このアプリケーションはこのデータベース上で実行されるか、または中間層Webサーバーなどが必要です。これらのアプリケーションの複雑さを考えると、実際には比較的簡単です。 データベースに合わせてWebサーバーを計測できる場合は、エンドツーエンドで実行できます。 エンドユーザークライアントのインスツルメントについては何も言わなかったことに気づきました。これは、実際に動的にインクルードするため、コードを変更する必要がないためです。 JavaScriptがアプリケーションページフレームに入ります。 ユーザーが世界のどこにいても、アプリケーションからURLにアクセスしてそのページをダウンさせると、Preciseが装備されます。 これにより、ユーザーID、IPアドレス、およびエンドユーザーブラウザー内の各ページコンポーネントスクリプトの実行時間の最初のバイトレンダリング時間を選択できます。
トランザクションに関しては、トランザクションが密結合されているため、マッピングする必要はありません。 このURLはJVMへのエントリポイントになり、このメッセージを呼び出して、データベースからJVCがキャッチされます。 基本的にそれらの自然な接続ポイントをキャッチし、そのトランザクション画面でそれらを表示することができます。また、各ステップで費やした時間または時間の割合も計算しました。 これらはすべて自動的に行われます。 一般的に、90分を割り当てて、基本的にPreciseコアをインストールしてから、アプリケーションの実装を開始します。 アプリケーションの知識によっては、アプリケーション全体を計測するために追加のセッションが必要になる場合があります。 多くの人がPreciseのデータベースコンポーネントのみを使用しています。 それはいいです。 基本的にこれを分割し、サイトで必要と思われるコンポーネントに分割できます。 階層間の依存関係が実際に個々の階層を監視する価値を高めることができるように、アプリケーションスタック全体をインスツルメントするというコンテキストが確実に考えられます。 誰かがアプリケーションスタックをさらに詳しく調べたい場合は、当社のWebサイトにアクセスしてください。追加の情報をリクエストする最も簡単な方法だと思います。これについては、もう少し詳しく説明します。
エリック・カバナ： 1つまたは2つの簡単な質問をお聞かせください。 さまざまなアプリケーションとさまざまなデータベース間の相互作用について、個々のクライアントおよび企業全体として、長期にわたってリポジトリを収集および構築していると思います。 つまり、シナリオモデリングは、私がほのめかしていることだと思います。 そうですか？ 特定の事柄が発生したときにエンドユーザーに提案できるように、実際に一般的なシナリオの一種のリポジトリを維持していますか？ このバージョンのE-Business Suite、このバージョンのこのデータベースなどと同様に、あなたはその多くをしていますか？
ビル・エリス：その種の情報は調査結果レポートに組み込まれています。 調査結果レポートには、パフォーマンスのボトルネックが何であるかが記載されており、実行時間に基づいています。 その調査結果レポートの一部は、詳細と、次に何をするかです。 顧客からの情報または経験などは、基本的にその推奨ライブラリに組み込まれます。
エリック・カバナ：わかりました、いいですね。 皆さん、今日は素晴らしいプレゼンテーションです。 ビル、私はあなたがそこにどれだけ詳細を持っているのが大好きでした。 これは本当に素晴らしく、ざらざらした、きめ細かい情報で、これらすべてがどのように行われるかを示していると思いました。 ある時点では、ほとんど黒魔術に似ていますが、実際にはそうではありません。 これは、非常に複雑な環境を理解し、アプリケーションをゆっくり実行するのが好きな人がいないため、人々を幸せにするために皆さんが組み上げた非常に特殊なテクノロジーです。
皆さん、このWebキャストをアーカイブします。 Techopediaまたはinsideanalysis.comにオンラインでアクセスできます。お時間をいただきありがとうございます。次回もご連絡いたします。 さようなら、気をつけて。
