REST APIを呼び出して、アプリケーションのイベントキュー、データベースクエリからの声明を開発し、このデータを更新し、負荷テスト時には、この単純なサービスは多くの問題があります。
いくつかの構成の問題イベントキューの消費者だけでなく、SQL文で問題。
1.複数のデータに同じパラメータ、更新ステートメントを渡しデッドロック
解決策：プライマリキーを使用して条件付き更新ステートメント
2.臨時サービスがタイムアウトがあるだろう、実際には、他の定期的なジョブがあり、サービスに影響を与え、時間がかかりすぎます
ソリューション：挿入されたデータをSQLの数を定義する別のジョブのタイミング
アプリケーションサーバは、CPUのデータの入ってくる部分を実行し、3。
解決策：モードがオートからキュークライアントになるだろうアクノリッジ、最大セッションのデフォルトは1
接続の最大数を定義しながら、JDBC
この後4.、設定されていない送信に一度のイベントに多くのデータベース接続要求ではなく、問題をもたらしている、それは一つだけ、遅い処理することができます
大きなに最大セッションデータの後に、キューレシーバが大きくなるが、唯一のキューComsumersにおけるデータ処理セッションが見られるものの
ソリューション：8にTIBCO EMS明示的なクライアント、そしてアプリケーションノードの流れを制限し、スレッド数の集合となり、クライアントのキューからの確認応答モード
この設定では、アプリケーションは同時に複数のデータを処理することができます
5.しかし、速度はアプリケーションノードのフローリミットを試した後、まだ満足のいくものではなく、スレッド数が16に設定されています
大量のデータを同時に投げたとき、5までキューMaxRedeliveryセットので、この時点では、このエラーメッセージがかご確認くださいいなかったので、キューが複数のメッセージの数倍でした
そして、さらに深刻なキューReceivermは劣らず、メッセージ内で、ありませんが、このプロセスはスレッドを生成し、まだサーバリソースを消費します
com.tibco.bw.palette.jms.runtime.fault.JMSEventContextFault：JMSメッセージを確認しようとしたときにエラーが発生しました
javax.jms.IllegalStateException：この消費者のためのメッセージを確認しよう（複数可）は無効
解決策：プロセスの消費者の、プラストライキャッチで
実際には6、本当のボトルネックは、クエリに表示されている、JDBCクエリがアプリのノードのアクティビティインスタンスの活動がONに設定され、クエリが実際に700〜1500ミリ秒を消費して見ることができます
このクエリは、クエリ文字列のGUIDフィールドに使用され、インデックスが作成されました
プログラムの存在BWクエリー結果のキャッシュ内の、Javaのグローバルインスタンスが動作する可能性方法を検討し始めたが、アクティブスペース、2.1バージョンはBW6を使用することはできません、これらは少し問題があります
私はSOAPUIでこのクエリを実行すると、我々は速度が1msで、BWとの速度は単純に行うには悪い日であることがわかりました
なぜBWでこのSQLはとても遅いのでしょうか？JDBCクエリモードは、事前の文で、SQL直接は速くなるはずですが、SQL直接はうまく機能しない、トラブルを変更します
だから、SQL SOAPUIが動作して置く見つけるためのSQLプロファイラツールで、数百ミリ秒は、元の文の文字列型はnvarchar型JDBCクエリを生成している必要が
この操作はしても、インデックスをヒットしなかったときにデータベースフィールドは、varchar型であります
対処方法：文の？（、VARCHAR（50）？）に変換するに変更、このようにして製造SQLがインデックスにヒットします