1

次のセットアップを実行しています。

物理サーバー Windows 2003 Standard Edition R2 SP2 IIS 6 ColdFusion 8 JT400 ドライバーを使用した iSeries AS400 への JDBC 接続

データベース内のファイルに対して単純な SQL クエリを実行しています。

SELECT
    column1,
    column2,
    column3,
    ....
FROM    LIB/MYFILE

条件なし。

このファイルには、英数字と数字の 81 列と、約 16,000 のレコードがあります。

STRSQL コマンドを使用してエミュレーターでクエリを実行すると、クエリがすぐに返されます。

Web サーバーでクエリを実行すると、約 30 秒かかります。

なぜこれが起こっているのですか?また、この時間を短縮する方法はありますか?

4

3 に答える 3

4

Web サーバーに関係する可能性のあるオーバーヘッドに対処することはできませんが、他にも考慮すべき要素がいくつかあると言えます。

これは、主に 2 つのシステム インターフェイスの動作方法の違いに関係している可能性があります。

対話型 STRSQL セッションは、データの最初の数ページを受け取るとすぐに結果の表示を開始します。その初期データをページダウンすることはできますが、通常、ある時点で、画面の下部にステータス メッセージが表示され、データがさらに取得されていることが示されます。

Web サーバーは、結果セット全体を受け取るまで待機していると思います。HTML ページを作成するときに、ページを送信する前にすべてのデータを取得する必要があります。したがって、当然、より長く待つことになります。

これが Web サーバー アプリケーションの動作ではない場合、JT400 JDBC プロパティの問題である可能性があります。

デフォルト設定を上書きした場合は、それらが適切であることを確認してください。

状況によっては、OPTIMIZATION_GOAL 設定が要因になることがあります。ただし、インデックスやキーを使用せずに、テーブル (物理ファイルまたは PF) を物理的な順序で直接読み取る場合は、ここでは当てはまらない可能性があります。

対話型 STRSQL セッションは、デフォルトで *FIRSTIO の設定になります。これは、データの最初のページをすばやく返すようにクエリが最適化されていることを意味します。これは、クエリの動作に対応しています。

拡張動的パッケージを使用していない限り、JDBC 接続はデフォルトで「0」の「クエリ最適化目標」に設定され、これは *ALLIO の OPTIMIZATION_GOAL 設定に変換されます。*ALLIO は、オプティマイザーが、最初のページだけでなく、結果セット全体を返すのに必要な時間を最小限に抑えようとすることを意味します。

または、最初FOR READ ONLYに SELECT ステートメントの最後に単純に追加してみてください。

更新: より高度なソリューション

送信される Web ページの構築の一環として、結果セット全体を待機することによって生じる遅延を回避できる場合があります。

レコードがない、または制限されたレコードなしで Web ページをブラウザーに送信しますが、AJAXコードを使用して残りのデータを舞台裏で読み込みます。

1 つのクリップで多くの行を取得するには、可能な限り大きなブロック フェッチを使用します。

于 2013-03-29T17:29:31.203 に答える
1

覚えておく必要があることの 1 つは、i は、ジョブで作成したアクセス パスを、再び必要になった場合に備えて保存することです。つまり、ログアウトして再度ログインしてからクエリを実行すると、実行に時間がかかり、2 回目にクエリを実行すると速くなります。Web アプリケーションでクエリを実行する場合、ジョブを再利用する場合と再利用しない場合があります。つまり、アクセス パスを再構築する必要があります。

スピード重視なら。私は...するだろう：

  1. クエリの最適化を検討してください。もっと良い情報源があることは知っていますが、今は見つけられません。
  2. ストアド プロシージャを作成します。ストアド プロシージャは、作成されたアクセス パスを保存します。
于 2013-03-29T14:49:35.103 に答える