c# - REST サービスのパフォーマンスを向上させる

Question

forループでストアドプロシージャを300回呼び出すメソッドがあり、ストアドプロシージャが1200レコードを返すたびに。どうすればこれを改善できますか? 300回の呼び出しを排除することはできませんが、他に試すことができる方法はありますか. ASP.NET を介して実装された REST サービスを使用し、データベース接続に IBATIS を使用しています

Answer 1

300回の通話をなくすことはできません

300 コールを排除します。

元のストアド プロシージャを 300 回呼び出す別のストアド プロシージャを追加して結果を集計するだけでも、パフォーマンスが大幅に向上するはずです。

元の機能を複製するが、特定のユースケースにより適切に構造化された新しいストアドプロシージャを作成し、代わりにそれを1回呼び出すことができれば、さらに良い.

コードとデータベースが同じシステム上にある場合でも、コードとデータベースの間で 300 回の往復を行うには時間がかかります。

このちょっとした恐ろしい問題が解決されたら、必要に応じて最適化できる他のものがあります。

Answer 2

ええと、360,000レコードを返す必要がある場合は、360,000レコードを返す必要があります。しかし、本当に360,000レコードを返す必要がありますか？そこから始めて、下に向かって進んでください。

Answer 3

測定。

サーバー側コード内で費やされた時間を測定します。ストアド プロシージャで費やされた時間を測定します。クライアント部分で費やされた時間を測定します。計算を行うと、ネットワーク時間とその他のオーバーヘッドの大まかな見積もりが得られます。

1200 件のレコードを返すと、ネットワーク帯域幅が主な問題の 1 つであると予想されます。別のシリアライゼーション エンジン (同じ出力タイプ) が役立つかどうか、または圧縮 (gzip / deflate) サポートを追加することが有益かどうか (つまり、必要な CPU の増加よりも帯域幅の削減の方が重要であるかどうか) を調べることができます。

REST サービスを 300 回呼び出す場合は、待ち時間が重要になる可能性があります。おそらく、わずかに並列化するか、小さな呼び出しをたくさんするよりも大きな呼び出しを少なくすることができます。

SQL コードをバッチ処理できるため、DB へのアクセスを数回行うだけで済みます (それぞれで SP を繰り返し呼び出します)。これは完全に可能です。etcを使用するだけですEXEC（まだパラメータ化を使用しています）。

ADO.NET から REST レイヤーにデータを取得する方法を確認できます。IBATISについて言及されていますが、これが「dapper」などと比較して速いか遅いかを確認しましたか？

最後に、SP のパフォーマンス自体を調べることができます。索引付けまたは SP の SQL の再構築が役立つ場合があります。

Answer 4

詳細をあまり知らなければ、アーキテクチャに欠陥があるように見えます。一方では、単一の SP 実行を使用して 360,000 レコードを取得するのにかかる 6 秒間テーブルをロックすることは不合理であると考えられますが、複数の SP 実行を介して取得される 360,000 レコードの一貫性のないセットを返すことは問題ありません。正確に何を実装しようとしているのか、クライアントとサーバー間の統合を設計するためのより良い方法があるかどうか疑問に思います.

たとえば、最後のリクエスト以降に作成された一連のレコードをクライアントが取得している場合は、ページ化された ATOM フィードの方が適している可能性があります。

何をしていても、360,000 レコードはサーバーとクライアント間で移動する大量のデータであり、現在のアプローチが適切であることを確認するために、そのデータ転送のアーキテクチャと目的を検討する必要があります。