0

私は現在、CodeFirstでEntityFramework4.2を使用しています。現在、AmazonEC2で実行されているWindows2008アプリケーションサーバーとデータベースサーバーがあります。アプリケーションサーバーには、1日に1回実行されるWindowsサービスがインストールされています。このサービスは次のコードを実行します。

// returns between 2000-4000 records
var users = userRepository.GetSomeUsers();

// do some work

foreach (var user in users)
{
    var userProcessed = new UserProcessed { User = user };
    userProcessedRepository.Add(userProcessed);
}

// Calls SaveChanges() on DbContext
unitOfWork.Commit();

このコードの実行には数分かかります。また、アプリケーションサーバーのCPUを最大限に活用します。私は次の対策を試しました：

  • unitOfWork.Commit（）を削除して、アプリケーションサーバーがデータベースと通信するときにネットワークに関連しているかどうかを確認します。これは結果を変えませんでした。
  • アプリケーションサーバーをAmazonのミディアムインスタンスからハイCPUインスタンスに変更して、リソースに関連しているかどうかを確認しました。これにより、サーバーはCPUを最大限に活用できなくなり、実行時間がわずかに改善されました。ただし、実行時間はまだ数分でした。

テストとして、上記のコードを3回実行するように変更して、同じDbContextを使用して2番目と3番目のループの実行時間が確認されました。連続するすべてのループは、前のループよりも実行に時間がかかりましたが、同じDbContextの使用に関連している可能性があります。

私は何かが足りないのですか？これほど単純なものを実行するのに数分かかる可能性は本当にありますか？各ループの後にデータベースにコミットしなくても？これをスピードアップする方法はありますか？

4

2 に答える 2

1

Entity Framework（現状）は、この種の一括操作にはあまり適していません。EC2で一括挿入方法の1つを使用できますか？そうしないと、T-SQLINSERTステートメントの手動コーディングが大幅に高速になる場合があります。パフォーマンスが重要な場合、それはおそらくEFを使用する利点を上回ります。

于 2012-04-24T20:03:36.410 に答える
0

私の推測では、ObjectContextは多くのエンティティインスタンスを蓄積しています。SaveChangesには、ロードされたエンティティの数に時間線形のフェーズがあるようです。これは、それがますます長くかかっているという事実の理由である可能性があります。

これを解決する方法は、複数の小さいObjectContextを使用して、古いエンティティインスタンスを削除することです。

于 2012-04-24T19:47:27.083 に答える