どのような組織は、エンタープライズアプリケーションは、2つの基本的な要件は、パフォーマンスの高い基準を達成することを確実にするために：負荷の場合は、モニタを近くの臨界状態にアプリケーションの能力;アプリケーションがQA、2フェーズデプロイメント（ステージング）、またはデプロイメント・フェーズであるか否かを、迅速に障害が発生した場合に、障害の根本原因を特定する能力を有します。
この話は本当である、本明細書中で使用される名前は、彼の本当の名前ではありません。
この記事では、Javaのパフォーマンス問題についての本当の脚本です。まず、それはワイリーエンタープライズJavaアプリケーション管理ソリューションと展開のパフォーマンス分析の再生の前と後のその役割の概要を説明します。その後、私は、パフォーマンスの低下のいくつかの例についてお話します。無視するJavaアプリケーションの管理はろうそくの価値があるなぜあなたは知っているだろう。
ワイリー4溶液
機関の健全な発展の成熟度とは、それが自然にポリシーと、それは「QUOT ;?混乱「状態、これらの」混乱を経験した中で行われた排除する一連の手順を開発し、ミッションクリティカルなJavaの務めましたこれらの機関との戦いでのアプリケーションのパフォーマンスの問題のプロセスは、アプリケーションパフォーマンスと巨大なオーバーヘッドが密接に関連していることを知っている：IT低利回りで投資、資金の流れとエンドユーザーの満足度の側面のリスク。
ワイリー・テクノロジーのワイリー4ソリューションは、アプリケーションのライフ・サイクル・モニターのいずれかの段階で企業を可能に改善する、エンタープライズJavaアプリケーションを管理します。
これは、Javaアプリケーションのパフォーマンスの問題は、IT組織内のすべての部門が、それは迅速に特定し、問題を修正するために使用できる共通言語を提供します。
ワイリー4では、チームはケース内に存在し、資金移動を見つけるために、業務アプリケーションの機能を中断することなく料金の支払い、商品の購入だけでなく、他のコアのパフォーマンスのボトルネックを24/7を監視する-ソースコードを変更すること、すべてのユースケースをそれは根本的なサーブレット、JSP、EJBにマッピングされ、そしてそのカスタムコードを達成することができます。カスタマイズ可能なテンプレートとの統合のさまざまなオプションは、ワイリー4が主流のシステム管理ソリューションを完全に補完となります。ワイリー4 Introscopeの警告に組織が既存の運用、トラブルシューティングのアプローチに発行されたことができます、警告が情報の可用性のアプリケーションクライアント機能を（図1を参照）が含まれています。
JavaアプリケーションのモニターIntroscopeを、潜在的なリークモニターメモリリークを識別するためのIntroscopeのシステムを、およびパフォーマンスの問題に関連したIntroscopeのトランザクション追跡の問題を解決：ワイリー4ソリューションの主要コンポーネントが含まれています。ワイリー4ソリューションは、システムに接続された支持Javaアプリケーションのパフォーマンス問題を特定し、バックエンド、IntroscopeをSQLエージェント、およびIntroscopeのパワーパックを含んでいます。
これらのソリューションは、完全なJava環境ビューの下の「全アプリケーション」を提供するために、互いに結合しています。
ネットワークパフォーマンスの監視：設定し、パフォーマンス目標を達成するため
のベストプラクティスとして、いくつかの機関は、参照のワイリーIntroscopeのセットは、キーコンポーネントとアプリケーションの応答、パフォーマンス目標を達成するための目的を記録します。エンタープライズJavaアプリケーションと展開の開発に成功し、連続コアベースライン測定を含めるべきである例を使用しますが、また、それらの開発に際する必要があります。開発者がアプリケーションを追加および変更する場合には、これらのベースラインは、アプリケーションのフォローアップバージョンを評価するためのハード統計的評価方法を提供することができます。あなたは慎重に、開発プロセスの各ステップを監視していないと、おそらくバグ、さらに悪いことに、ボトルネックアーキテクチャの多くに遭遇する場合。2フェーズ・コミットまたは生産段階、その後、これらのボトルネックを修復した場合、コストは大きくなります。
あなたが満足のいく答えを得るまでは良い探偵のように、良いベースラインまたはベンチマークは常に同じ質問をします。このプロセスを繰り返しソフトウェアのパフォーマンスを改善するための最も効果的な方法であることが自分自身を証明した「あなたが跳躍する前に見て」アプローチの種類を奨励しています。
正常にロードされ、すべてのアプリケーションのための重要なユースケースは、アプリケーションがすべての機能を持っている必要があります。二回優れた整合性チェックの同等の果たす役割に関して良好なパフォーマンス負荷ジェネレータのスクリプトアプリケーションのコア機能検査の期間。
アプリケーションが負荷の下で実行されると、我々は常に、特に製品段階の最初の数ヶ月で、ボトルネックを特定するために、機能レベルでその性能から機関を監視する必要があります。
ワイリーのIntroscope詳細はビューにJavaの指標と報告手順から抽出することができ、実際のパフォーマンスのアプリケーションを説明します。最も一般的なペットショップの例では、メトリックは、商品調達、リターン領収書、カタログを見て、在庫の他の側面を探しのためです。この方法を使用すると、調整は、それが遅いので、もはや動機のコンポーネントではありませんが、顧客が戻り領収書に必要な時間を見つけるために許容できない程度まで成長します。このようなビューがなければ、あなたはパフォーマンスチューニングに貴重な開発時間を浪費することがありますが、アプリケーションの成功の全体的なパフォーマンスは問題ではない可能性があります。
ワイリーのIntroscopeを、コールの数とクライアントアプリケーションのすべての主要コンポーネントの平均値、最小値と最大応答時間を報告することができます。Introscopeをまた、I / O統計、プールされたリソース使用率の統計情報（例えば、MQ接続）、環境並行性（またはビジネス監視スレッドの各論理コンポーネントのための方法）、およびメモリ統計、ファイルやソケットを監視します統計など。
プロトタイプのJ2EEアプリケーションでは、コントローラサーブレットとして動作し、EJBは、モデル（例えば、JDBC、MQシリーズなど）、バックグラウンドコネクタのAPIとして機能し、JSPビューが監視されるように動作します。あなたがソースコードを変更することなく、特定のビジネスロジックや背景コネクタを監視できるように追加の手段は、多くの場合、簡単にカスタマイズIntroscopeのステップを取ります。例えば、Introscopeのは大手航空会社、通信会社、レガシーメインフレームのコールバック、そして数え切れないほど、このようなカスタムビジネスロジックを実行し、バックエンドシステムで、それはSABERの業務を監視するタスクを完了したとき。
アプリケーションプログラムからのデータは、CSVフラットファイルデータベースと主流に記録し、又は負荷生成ツールに直接統合されてもよいです。
各顧客は、彼らのニーズのデータの記録および分析のために最も適したを選択することができます。データは自動的にスクリプトの自動化の報告とクリーンアップに役立つファイル構成された制限に従って行うことができるファイルに書き込まれます。いくつかの一般的に使用されるデータベースには、スクリプトを得るために使用することができるデータの例が含まれています。
この記事の残りの部分では、いくつかのIntroscopeの本当の例の使用に焦点を当てています。
「それは重要な睡眠である」
フィラデルフィア、月曜日、曇り、冷たいです。私は一日のシフトを重視します。お客様が自社のアプリケーションは、2段階に分けて展開され、保険会社です。
私たちの監視プログラムがAUDITと呼ばれ、それがWebフロントエンドのレガシーグリーンスクリーンアプリケーションです。
新しい保険ポリシーを作成するアプリケーションを使用するお客様の保険代理店。AUDIT CICSは、JSPにそれらを解析し、その後、主にバックエンドのデータとして使用され、新しいプロセスに使用されてきた同じ30年のレガシーストアドプロシージャによると、。ページは1-2秒でロードされるように設計されていますが、各要求は、7-8秒を費やし必要です。CICSからのデータは、すべての要求がすぐに対処されていることを示しています。だから、問題は、それがどこであるのですか？私たちはすぐにその理由を確認する必要があります。
各トランザクションを呼び出すために50〜60時間を必要とするが、各コールの応答時間はわずか100ミリ秒以下のとおりです。ワイリーIntroscopeを実行するカスタムデータは、分析的手続の適用上のトラッカーが示すオブジェクト。調査データオブジェクトの構築は、プレースホルダ・ロジックの開発を明らかにしています。
各オブジェクトは、一意のIDが必要です。したがって、コンストラクタ100ミリ秒のスリープを準備し、唯一の目的は、システムクロックを呼び出すことにより、タイムスタンプを生成することです。
結果：開発者は、もはやリモートスリープ時間を設定します。
「欠陥豆の冒険」
火曜日の午後にテキサス州、。私は顧客だと一緒に、このクライアントは、アプリケーションを解決しようと数ヶ月のためにパフォーマンスの問題をテストするのに苦労します。彼はコアダンプと答えたように私は、ワトソン博士に相談したとき。
応答時間があるので、ユーザーが購入の製品段階では、この例では遅すぎるのアプリケーションは、おそらく30％を失うことになります。信じられないほど多くの要求が2分以上を実行する必要があり、その後、タイムアウトしました。Introscopeのはすぐに方法でパフォーマンスのボトルネックは、方法は、発注エントリの売上税を計算するのに使用されていることを発見しました。構成は、本実施形態のインターフェースで実施されるサービスロジックのすべてを追跡するのに十分なIntroscopeを唯一の行です。
さらに検討を通じ、私たちは、この方法は、Runtime.execのは、新しいJVMを呼び出して使用することがわかりました。プロセスに加えて、この新しいJVMは単一のエントリ売上税を計算して、システム出力に結果を出力します。アプリケーションサーバは、辛抱強く、この出力を待って、その後、各エントリに対して同じことを繰り返します。通常の負荷条件の下で、50〜60までのJVMは、オンとオフを同時に開始され、それぞれ約20〜40秒間待つ必要があります。
我々はそれを見つけ：失われたトランザクションを、両方の複数の購入取引のエントリで、その理由は？開発者は、消費税の計算を完了するために、サードパーティ製の税額計算ソフトウェアのEJBのインタフェースが含まれている割り当てられているが、彼は、サーバーのコンテキストにロードされたソフトウェアを置くことができませんでした。方法はありません、彼はソフトウェアのサンプル・コードに頼る必要があったので、彼は一例にスクリプトを書き換え、スクリプトが適切なパラメータに送信され、システムの出力結果でコマンドラインプログラムを生成しています。
結果：容疑の調査結果は、Perlスクリプト言語の無実を証明します。容疑者が解雇されました。この例では、終了します。
「その後、何も（JDBCカーソル）」
その日は遠い歴史の中で有名なボストンパブリック緑地から水曜日と私ではありません。負荷試験長いプロセスでは、私のクライアントは、常にすべてのJDBCカーソルとMQシリーズの接続を排出します。割り当てとこれらの資源の回復の文のための狡猾Introscopeをモニターしました。Introscopeを非難の特性と、すぐに間違ったEJBを識別チーム：高負荷条件下では、アプリケーションが例外をスローし、重要近い呼び出しを飛ばした結果が、彼らはプログラムに含まれている必要がありますが、最後のブロックを実行しましたしたがって、リソースの解放を保証します。
結果：さて、無事に最後のブロックの後に置かれている「オフ」を失います。
「ヘルプの同期の問題について、」
木曜日、私の犬が吠えます。コーヒーの彼の第五杯を終え、私が出て行きます。
平均取引の狡猾Introscopeの対策専用のバック応答時間が10秒です。
10しかし、負荷試験、90-100秒の間にバックグラウンドシステムへのトランザクションの平均応答時間の同時ユーザー。これは、明確なバックグラウンドシステムが同時に要求を処理しないで、面白いです。呼び出しで同時測定基準を使用することにより、我々はすぐに欠陥を識別：9つの同時ユーザー・スレッドをコールしてバックエンドシステムに待機して、実際の処理タスクでスレッドを1つだけ。
リソースプールを使用すると、リモートアクセスサーバーの応答を失っする必要がある唯一のインスタンスの10個のインスタンスを持つ必要があり、誤ってsynchronizedキーワードクラスに入れるのではなくメソッドのシンボルに：ワイリーの同時測定は、次の質問をキャプチャすることができます。この場合、アプリケーションが予期せぬシステム障害の背景を扱うことができないため、コールの有効期限が切れる数秒で、この結果のリターンが得られ、数分または数時間を過ごすことになります。同時実行は、私たちに簡単に製品段階で同様の障害に対処するために、よりエレガントな方法を可能にするアプリケーションから、このような欠陥に迅速かつ簡単な方法を見つけることです。
結果：低潮の製品段階でその所有者のためのアプリケーションとツール。
「マルタの結果セット」
今日は金曜日ですが、私はアトランタにいますよ。そんなに良くちょうど桃がたくさんあると言うために路上で多くの木があります。
顧客は、大規模なデータベースの結果セットにトラブルに走りました。
何のビルドこのような戦略がないため：それは、クエリを制限することができることを保証し、かつ合理的な成長に支払われているが、アプリケーションサーバ内の私のクライアントは、「豚のpythonで」メモリ障害を発生させます。エラーを検索するか、検索するJVMのGCメモリ・スタック上のどこにでも横行につながりました。楽に結果セットが読み込まれる方法に従って、与えられたアプリケーション・サーバのデータベースには、これは、アプリケーションに応じて、他のトランザクションの中で最も深刻な副作用が深刻な外部の被害をもたらしています。
データベースクエリの応答時間と「往復」一貫性のない応答時間を指摘することにより、ワイリーのIntroscopeのSQLエージェントがすぐに故障を診断します。後者の尺度はクローズされた結果セットの前に費やしたすべてのシステム・クロックの時間が含まれていますが、前者はそれが取得データベースへの応答に要する時間だけが含まれています。往復の応答時間と対応策の間には大きな違いがあります。もちろん、この措置は、アプリケーションサーバ内からキャプチャすることができます。
結果：開発チームは、必要な変更を行いました。アプリケーションは完全に形質転換し、社会の中で自分の役割を果たしています。
「殺人JDBC Expressは、」
私はサンフランシスコで土曜日に仕事に志願しました。最後に、顧客がラスベガスを訪れた後、私は残業する必要があります。
私は、JDBC災害の端からどこまでを知りません。顧客は、おそらく、ほとんどが浮上し、上下1ミリ秒内に10ミリ秒の測定平均に関する重要なデータベーストランザクション応答時間--JDBC文を調整する方法を学びました。
これらの問題は、それが起こったのかの範囲を超えていますか？私は、Introscopeのトランザクション追跡アプリケーションを使用し、標準負荷の下で生じる30ミリ秒のトランザクションを記録しました。
過去には、何の統合ツールは、ユーザーが「有罪」のアプローチを見つけることができませんがあります。さて、トランザクショントラッカーコールグラフは、森の中のすべての木を見るために顧客を有効にする、Introscopeのは自動的に不要なデータを削除する使用：単一のトランザクションは、ほぼ4000 JDBC文につながりました。でもデータベース応答、非常に多くのクエリはまた、誤動作を引き起こすのに十分であり得ます。
各チェック方法は、6つの呼び出しからJDBCステートメントを処理する責任がある - このメソッドの呼び出しは、各トランザクションでJDBC文の約40％を占め：トランザクション追跡の分析があることを示しています。これらのチェックを達成するためのバッファリング戦略の使用 - 仕事の日よりも少ない - 開発チームは、わずかな変更となっています。CPU使用率と処理時間が降りてくる、生産性が向上しています。
結果：データベースが完全に修復されたが、それ以来、開発チームは、スイングを開発するために指定されています。
「私は、Vectorのあまりを知っている」
土曜の夜、長い週末を。霧を通して街の明かりが出て撃ちました。電話が鳴ったとき、私はライ・ウイスキーのグラスだったとき。
お客様は、EJBリモートインタフェースの直接呼び出しであるJ2EEアーキテクチャに基づいた取引システムを、持っています。数ヶ月前、彼らは今、問題のCPUの過負荷を経験し、生産性を減少している、JMS実装を置き換えます。各取引に付随する「使用中のGCヒープのバイトは、」出現し続け、最終的にメモリ例外につながりました。
開発チームは、すべての一般的に使用される統合ツール（プロファイリングツール）で実験が、誰がリークの原因を発見することはできません。（図3を参照）。
ベクターは、アプリケーションによって使用されるデータ構造の唯一の45,000種類ある - ワイリーIntroscopeをリークを迅速ベクトルの異常成長を発見し監視します。一時的に高速ロールバックバッファトランザクション識別子を含むベクター問題。アプリケーションの数がトランザクションを増加すると、ベクタも増加します。新しいJMS実装が予期しない結果を引き起こしたときのベクトルへのコールが「含まれている」とき。「含まれている」と呼ばれているこのエラーの説明は、各トランザクションがエントリの増加した、トランザクションが成長し、新しいベクトルにつながります。
結果：ベクトルを嫌いになりましたビクターの名前に置き換えられている、それがうまくフロリダで証人保護プログラムを実行しています。
長い別れの終わりには、私は夜に歩きました。次のケースが行われる場所を私は知りません。
| 著者について | |
| デイブ・マーティンはワイリーテクノロジー企業、システムエンジニアです。彼は多くの企業顧客のために働いている、主な仕事は、Javaアプリケーションにおけるパフォーマンスの問題を特定して修正することです。ワイリー・テクノロジー、かつてのソフトウェア開発者として、DaveはJ2EEのソフトウェアシステムのアーキテクチャの側面のアーキテクチャ、設計と実装の豊富な知識を持っています。 | |
ます。https：//www.cnblogs.com/kapok/archive/2005/10/15/255401.htmlで再現