Entity Framework가 너무 느립니다. 내 옵션은 무엇입니까? [닫은]

"Do n't Optimize Prematurely"만트라를 따르고 Entity Framework를 사용하여 WCF 서비스를 코딩했습니다.

그러나 성능을 프로파일 링했으며 Entity Framework가 너무 느립니다. (내 앱은 약 1.2 초 만에 2 개의 메시지를 처리하는데, 다시 작성중인 (레거시) 앱은 동시에 5-6 개의 메시지를 처리합니다. (레거시 앱은 DB 액세스를 위해 sprocs를 호출합니다.)

내 프로파일 링은 Entity Framework가 메시지 당 많은 시간을 차지한다는 것을 가리 킵니다.

그래서 내 옵션은 무엇입니까?

• 더 나은 ORM이 있습니까?
  (일반적인 객체 읽기 및 쓰기를 지원하고 빠르게 수행하는 것 ..)

• Entity Framework를 더 빠르게 만드는 방법이 있습니까?
  ( 참고 : 내가 더 빨리 말한다는 것은 첫 번째 통화가 아니라 장기를 의미합니다. 메시지.)

• 서비스 속도를 높이는 데 도움이되는 신비한 세 번째 옵션입니다.

참고 : 대부분의 DB 상호 작용은 생성 및 업데이트입니다. 나는 선택과 삭제를 거의하지 않습니다.

Entity Framework에서 실제로 실행 한 SQL 명령을 프로파일 링하여 시작해야합니다. 구성 (POCO, 자체 추적 엔터티)에 따라 최적화 할 여지가 많습니다. ObjectSet<T>.ToTraceString()메서드를 사용하여 SQL 명령 (디버그 모드와 릴리스 모드간에 다르지 않아야 함)을 디버깅 할 수 있습니다 . 추가 최적화가 필요한 쿼리가 발생하면 몇 가지 프로젝션을 사용하여 수행하려는 작업에 대한 자세한 정보를 EF에 제공 할 수 있습니다.

예:

Product product = db.Products.SingleOrDefault(p => p.Id == 10);
// executes SELECT * FROM Products WHERE Id = 10

ProductDto dto = new ProductDto();
foreach (Category category in product.Categories)
// executes SELECT * FROM Categories WHERE ProductId = 10
{
    dto.Categories.Add(new CategoryDto { Name = category.Name });
}

다음으로 대체 될 수 있습니다.

var query = from p in db.Products
            where p.Id == 10
            select new
            {
                p.Name,
                Categories = from c in p.Categories select c.Name
            };
ProductDto dto = new ProductDto();
foreach (var categoryName in query.Single().Categories)
// Executes SELECT p.Id, c.Name FROM Products as p, Categories as c WHERE p.Id = 10 AND p.Id = c.ProductId
{
    dto.Categories.Add(new CategoryDto { Name = categoryName });
}

방금 머릿속에서 입력 했으므로 이것이 정확히 실행되는 방법은 아니지만 쿼리에 대해 아는 모든 것을 말하면 EF가 실제로 몇 가지 멋진 최적화를 수행합니다 (이 경우에는 범주가 필요함). 이름). 그러나 이는 예상로드 (db.Products.Include ( "Categories"))와는 다릅니다. 프로젝션은로드 할 데이터의 양을 더 줄일 수 있기 때문입니다.

문제는 Entity Framework와 같은 제품이 훨씬 더 많은 코드를 실행하기 때문에 항상 느리고 비효율적이라는 것입니다.

또한 사람들이 LINQ 쿼리를 최적화하고, 생성 된 SQL을보고, 디버거를 사용하고, 사전 컴파일하고, 많은 추가 단계를 수행해야한다고 제안하는 것은 어리석은 일입니다. 즉, 많은 시간을 낭비합니다. 아무도 말하지 않습니다-단순화하십시오! 모두는 더 많은 단계를 밟아 (시간 낭비) 일을 더 복잡하게 만들고 싶어합니다.

상식적인 접근 방식은 EF 또는 LINQ를 전혀 사용하지 않는 것입니다. 일반 SQL을 사용하십시오. 그것은 잘못된 것이 아닙니다. 프로그래머들 사이에 무리의 사고 방식이 있고 거기에있는 모든 신제품을 사용하려는 충동을 느낀다고해서 그것이 좋다거나 작동 할 것이라는 의미는 아닙니다. 대부분의 프로그래머는 대기업에서 발표 한 모든 새로운 코드를 통합하면 더 똑똑한 프로그래머가된다고 생각합니다. 전혀 사실이 아닙니다. 스마트 프로그래밍은 대부분의 경우 두통과 불확실성을 줄이고 최소한의 시간에 더 많은 작업을 수행하는 방법에 관한 것입니다. 기억하십시오-시간! 이것이 가장 중요한 요소이므로 단순히 '패턴'이라고 불리는 이상한 일부를 따르기 위해 작성된 불량 / 비대해진 코드로 문제를 해결하는 데 낭비하지 않는 방법을 찾으십시오.

휴식을 취하고, 삶을 즐기고, 코딩에서 휴식을 취하고, 추가 기능, 코드, 제품, '패턴'사용을 중단하십시오. 인생은 짧고 코드의 수명은 더 짧으며 확실히 로켓 과학이 아닙니다. LINQ, EF 등의 계층을 제거하면 코드가 효율적으로 실행되고 확장되며 유지 관리가 쉽습니다. 너무 많은 추상화는 나쁜 '패턴'입니다.

그리고 그것이 당신의 문제에 대한 해결책입니다.

한 가지 제안은 단일 레코드 CRUD 문에만 LINQ to Entity Framework를 사용하는 것입니다.

더 많은 관련 쿼리, 검색,보고 등의 경우 저장 프로 시저를 작성하고 MSDN에 설명 된 대로 Entity Framework 모델에 추가합니다 .

이것은 몇 개의 내 사이트에서 취한 접근 방식이며 생산성과 성능 사이에서 좋은 절충안 인 것 같습니다. Entity Framework는 당면한 작업에 대해 항상 가장 효율적인 SQL을 생성하지는 않습니다. 이유를 파악하는 데 시간을 소비하는 대신 더 복잡한 쿼리에 대한 저장 프로 시저를 작성하면 실제로 시간을 절약 할 수 있습니다. 프로세스에 익숙해지면 저장된 프로 시저를 EF 모델에 추가하는 것이 너무 번거롭지 않습니다. 물론이를 모델에 추가 할 때 얻을 수있는 이점은 ORM을 사용하여 강력한 유형의 장점을 모두 얻을 수 있다는 것입니다.

순수하게 데이터를 가져 오는 경우 EF가 가져 오는 항목을 추적하지 않도록 지시하면 성능에 큰 도움이됩니다. MergeOption.NoTracking을 사용하여이 작업을 수행하십시오. EF는 쿼리를 생성하고, 실행하고, 결과를 개체로 역 직렬화 할뿐, 엔터티 변경 사항이나 그 특성을 추적하지 않습니다. 쿼리가 단순하다면 (데이터베이스가 반환 될 때까지 많은 시간을 소비하지 않음) NoTracking으로 설정하면 쿼리 성능이 두 배가 될 수 있음을 발견했습니다.

MergeOption 열거 형에 대한 MSDN 문서를 참조하십시오.

ID 확인, 상태 관리 및 변경 추적

이것은 EF 성능에 대한 좋은 기사 인 것 같습니다.

성능 및 Entity Framework

애플리케이션을 프로파일 링했다고 말합니다. ORM도 프로파일 링했습니까? EF 코드를 최적화 할 수있는 부분을 강조하는 Ayende의 EF 프로파일 러가 있습니다. 여기에서 찾을 수 있습니다.

http://efprof.com/

성능을 확보해야하는 경우 ORM과 함께 기존 SQL 접근 방식을 사용할 수 있습니다.

더 빠르고 더 나은 ORM이 있다면? 객체 / 데이터 모델에 따라 Dapper , Massive 또는 PetaPoco 와 같은 마이크로 ORM 중 하나를 사용하는 것을 고려할 수 있습니다.

Dapper 사이트는 다른 ORM과 비교하는 방법에 대한 아이디어를 제공하는 몇 가지 비교 벤치 마크를 게시합니다. 그러나 마이크로 ORM이 EF 및 NH와 같은 전체 ORM의 풍부한 기능 세트를 지원하지 않는다는 점은 주목할 가치가 있습니다.

RavenDB를 살펴볼 수 있습니다 . 이것은 매핑이 필요 없이 POCO를 직접 저장할 수있는 비 관계형 데이터베이스 (Ayende에서 다시 제공)입니다 . RavenDB는 읽기에 최적화되어 있으며 스키마를 조작하고 객체를 해당 스키마에 매핑 할 필요가 없으므로 개발자의 삶을 훨씬 더 쉽게 만듭니다. 그러나 이것은 ORM 접근 방식을 사용하는 것과는 상당히 다른 접근 방식이며 제품 사이트에 설명되어 있습니다 .

@Slauma의 답변은 여기 에서 속도를 높이는 데 매우 유용합니다. 나는 삽입과 업데이트 모두에 동일한 종류의 패턴을 사용했고 성능이 급등했습니다.

내 경험상 EF가 아니라 ORM 자체의 문제입니다.

일반적으로 모든 ORM은 최적화 된 쿼리가 아닌 N + 1 문제로 고통받습니다 . 내 최선의 추측은 성능 저하를 유발하는 쿼리를 추적하고 ORM 도구를 조정하거나 SPROC로 해당 부분을 다시 작성하는 것입니다.

이것은 프레임 워크가 아닌 간단한 비 ORM 옵션으로 30 개 정도의 필드로 초당 10,000으로로드됩니다. 오래된 랩톱에서 실행하므로 실제 환경에서보다 빠를 것입니다.

https://sourceforge.net/projects/dopersistence/?source=directory

이 문제도 만났습니다. 너무 잘 작동하기 때문에 EF에 덤프하는 것이 싫지만 느립니다. 대부분의 경우 레코드를 찾거나 업데이트 / 삽입하고 싶습니다. 이와 같은 간단한 작업조차도 느립니다. 테이블에서 1100 개의 레코드를 목록으로 되 돌렸고이 작업은 EF에서 6 초가 걸렸습니다. 저에게 이것은 너무 길고 저축조차 너무 오래 걸립니다.

나는 결국 나만의 ORM을 만들었습니다. 데이터베이스에서 동일한 1100 개의 레코드를 가져 왔고 ORM은 EF보다 훨씬 빠른 2 초가 걸렸습니다. 내 ORM의 모든 것이 거의 즉각적입니다. 현재 유일한 제한은 MS SQL Server에서만 작동하지만 Oracle과 같은 다른 서버에서도 작동하도록 변경할 수 있다는 것입니다. 나는 지금 모든 것에 MS SQL Server를 사용합니다.

내 ORM을 시도하고 싶다면 여기 링크와 웹 사이트가 있습니다 :

https://github.com/jdemeuse1204/OR-M-Data-Entities

또는 너깃을 사용하려는 경우 :

PM> 설치 패키지 OR-M_DataEntities

문서도 거기에 있습니다

프로파일 링 한 후에 만 ​​최적화하는 것이 합리적입니다. DB 액세스가 느리다는 것을 알게되면 저장 프로 시저 사용으로 변환하고 EF를 유지할 수 있습니다. 느린 것이 EF 자체라는 것을 알게되면 다른 ORM으로 전환하거나 ORM을 전혀 사용하지 않아야 할 수 있습니다.

초당 120 개의 요청을 쉽게 수행하는 유사한 응용 프로그램 (Wcf-> EF-> 데이터베이스)이 있으므로 EF가 여기서 문제가되지 않는다고 확신합니다. 즉, 컴파일 된 쿼리로 성능이 크게 향상되었습니다.

나는 EF, LINQ to SQL 및 dapper를 사용했습니다. Dapper가 가장 빠릅니다. 예 : 각각 4 개의 하위 레코드가있는 1000 개의 메인 레코드가 필요했습니다. LINQ to sql을 사용했는데 약 6 초가 걸렸습니다. 그런 다음 dapper로 전환하여 단일 저장 프로 시저에서 2 개의 레코드 세트를 검색하고 각 레코드에 대해 하위 레코드를 추가했습니다. 총 시간은 1 초입니다.

또한 저장 프로시 저는 교차 적용과 함께 테이블 값 함수를 사용했으며 스칼라 값 함수가 매우 느리다는 것을 발견했습니다.

내 조언은 EF 또는 LINQ to SQL을 사용하고 특정 상황에서는 멋지게 전환하는 것입니다.

Entity Framework는 자체적으로 주요 병목 현상을 일으키지 않아야합니다. 다른 원인이있을 가능성이 있습니다. EF를 Linq2SQL로 전환 할 수 있습니다. 둘 다 비교 기능이 있고 코드를 쉽게 변환 할 수 있어야하지만 대부분의 경우 Linq2SQL이 EF보다 빠릅니다.