엔티티 프레임워크를 "준비"하는 방법은 무엇입니까?언제 추워집니까?

엔티티 프레임워크를 "준비"하는 방법은 무엇입니까?언제 추워집니까?

아니요, 제 두 번째 질문에 대한 대답은 겨울이 아닙니다.

서문:

저는 최근에 Entity Framework에 대해 많은 연구를 하고 있는데, 계속해서 신경이 쓰이는 것은 쿼리가 준비되지 않았을 때의 성능, 이른바 콜드 쿼리입니다.

Entity Framework 5.0에 대한 성능 고려 사항 문서를 검토했습니다.저자들은 따뜻한 질문과 차가운 질문의 개념과 그것들이 어떻게 다른지를 소개했는데, 저도 그것들의 존재를 모르고 있는 저 자신을 주목했습니다.여기서 언급할 가치가 있을 것입니다. 저는 6개월의 경력밖에 없습니다.

이제 성능 측면에서 프레임워크를 더 잘 이해하려면 어떤 주제를 추가로 연구할 수 있는지 알게 되었습니다.안타깝게도 인터넷에 있는 대부분의 정보는 구식이거나 주관적으로 부풀려져 있기 때문에 웜 대 콜드 쿼리 항목에 대한 추가 정보를 찾을 수 없습니다.

기본적으로 지금까지 제가 주목한 것은 재컴파일을 하거나 리사이클링 히트를 할 때마다 초기 쿼리가 매우 느려진다는 것입니다.예상대로 후속 데이터 읽기 속도가 빠릅니다(주관적).

Windows Server 2012, IIS8 및 SQL Server 2012로 마이그레이션할 예정이며, 주니어 시절에는 다른 서버보다 먼저 테스트할 수 있는 기회를 얻었습니다.저는 그들이 첫 번째 요청을 위해 제 애플리케이션을 준비할 준비 모듈을 도입해서 매우 기쁩니다.하지만 엔티티 프레임워크를 어떻게 준비해야 할지 잘 모르겠습니다.

제가 이미 알고 있는 것은 할 가치가 있습니다.

• 제안된 대로 미리 내 보기를 생성합니다.
• 최종적으로 모델을 별도의 어셈블리로 이동합니다.

상식적으로 제가 생각하는 것은 아마도 잘못된 접근법일 것입니다.

• Application Start(애플리케이션 시작)에서 더미 데이터 읽기를 수행하여 워밍업, 모델 생성 및 유효성 검사를 수행합니다.

질문:

• 언제든지 내 엔터티 프레임워크에서 고가용성을 유지할 수 있는 가장 좋은 방법은 무엇입니까?
• 엔터티 프레임워크가 다시 "냉랭"이 되는 경우는 어떤 경우입니까?(재컴파일, 재활용, IIS 재시작 등)

• 언제든지 내 엔터티 프레임워크에서 고가용성을 유지할 수 있는 가장 좋은 방법은 무엇입니까?

미리 생성된 보기와 정적 컴파일된 쿼리를 함께 사용할 수 있습니다.

정적 컴파일된 쿼리는 빠르고 쉽게 작성할 수 있으며 성능을 향상시키는 데 도움이 되므로 유용합니다.그러나 EF5를 사용하면 EF가 쿼리 자체를 자동 컴파일하기 때문에 모든 쿼리를 컴파일할 필요가 없습니다.유일한 문제는 캐시를 스위프할 때 이러한 쿼리가 손실될 수 있다는 것입니다.따라서 매우 드물지만 비용이 많이 드는 쿼리에 대한 자체 컴파일된 쿼리에 대한 참조를 유지해야 합니다.이러한 쿼리를 정적 클래스에 넣으면 쿼리가 처음 필요할 때 컴파일됩니다.일부 쿼리에는 너무 늦기 때문에 응용프로그램을 시작하는 동안 이러한 쿼리를 강제로 컴파일해야 할 수 있습니다.

언급한 것처럼 뷰를 미리 생성하는 것도 가능합니다.특히 컴파일하는 데 시간이 많이 걸리고 변경되지 않는 쿼리의 경우에는 더욱 그렇습니다.이렇게 하면 성능 오버헤드를 런타임에서 컴파일 시간으로 이동할 수 있습니다.또한 지연이 발생하지 않습니다.하지만 물론 이러한 변화는 데이터베이스로 전달되기 때문에 처리하기가 쉽지 않습니다.코드가 더 유연합니다.

TPT 상속을 많이 사용하지 마십시오(EF의 일반적인 성능 문제임).상속 계층을 너무 깊게 구성하거나 너무 넓게 구성하지 마십시오.일부 클래스에 특정한 2-3개의 속성만 있으면 고유한 유형이 필요하지 않을 수 있지만 기존 유형에 대한 선택적(nullable) 속성으로 처리할 수 있습니다.

하나의 맥락을 오래 붙잡지 마세요.각 컨텍스트 인스턴스에는 크기가 커질수록 성능이 저하되는 고유한 1단계 캐시가 있습니다.컨텍스트 생성 비용은 저렴하지만 컨텍스트의 캐시된 엔티티 내에서 상태 관리 비용이 많이 들 수 있습니다.다른 캐시(쿼리 계획 및 메타데이터)는 컨텍스트 간에 공유되며 AppDomain과 함께 사라집니다.

전반적으로 컨텍스트를 자주 할당하고 짧은 시간 동안만 사용해야 하며, 응용 프로그램을 빠르게 시작할 수 있고, 거의 사용되지 않는 쿼리를 컴파일하고, 성능이 중요하고 자주 사용되는 쿼리에 대해 미리 생성된 보기를 제공해야 합니다.

• 엔터티 프레임워크가 다시 "냉랭"이 되는 경우는 어떤 경우입니까?(재컴파일, 재활용, IIS 재시작 등)

기본적으로 앱 도메인을 잃을 때마다.IIS는 29시간마다 재시작을 수행하므로 사용자가 인스턴스를 사용할 것이라고 보장할 수 없습니다.또한 일정 시간 동안 활동이 없으면 AppDomain도 종료됩니다.당신은 다시 빨리 올라오도록 노력해야 합니다.초기화 중 일부를 비동기식으로 수행할 수도 있습니다(단, 멀티스레딩 문제는 주의하십시오).AppDomain의 종료를 방지하기 위한 요청이 없는 동안 응용 프로그램에서 더미 페이지를 호출하는 예약된 작업을 사용할 수 있지만 결국에는 종료됩니다.

또한 구성 파일을 변경하거나 어셈블리를 변경할 때 다시 시작해야 한다고 가정합니다.

모든 통화에서 최대의 성능을 원하는 경우 아키텍처를 신중하게 고려해야 합니다.예를 들어, 애플리케이션이 로드될 때 모든 요청에 대해 데이터베이스 호출을 사용하는 대신 서버 RAM에서 자주 사용되는 조회를 미리 캐시하는 것이 합리적일 수 있습니다.이 기술은 일반적으로 사용되는 데이터에 대한 최소 응용 프로그램 응답 시간을 보장합니다.그러나 동시성 문제를 방지하려면 캐시된 데이터에 영향을 미치는 변경 사항이 발생할 때마다 올바른 만료 정책을 사용하거나 항상 캐시를 지워야 합니다.

일반적으로 로컬로 캐슁된 정보가 오래되었거나 트랜잭션이 필요한 경우에만 IO 기반 데이터 요청이 필요하도록 분산 아키텍처를 설계해야 합니다.일반적으로 "무선" 데이터 요청을 검색하는 데 로컬 메모리 캐시 검색보다 10-1000배 더 오래 걸립니다.이 한 가지 사실만으로도 "콜드 데이터 대 웜 데이터"에 대한 논의는 "로컬 데이터 대 원격 데이터" 문제에 비해 종종 무의미합니다.

일반적인 팁.

• 액세스 대상 및 요청 시간을 포함하여 엄격한 로깅을 수행합니다.
• 응용 프로그램을 초기화할 때 더미 요청을 수행하여 이전 단계에서 선택한 매우 느린 요청을 웜 부팅합니다.
• 실제 문제가 아니라면 최적화하는 데 애쓰지 말고 애플리케이션 소비자와 소통하고 문의하십시오.최적화가 필요한 것을 파악하기 위해서만 지속적인 피드백 루프를 갖는 것이 좋습니다.

이제 더미 요청이 잘못된 접근법이 아닌 이유를 설명하겠습니다.

• 덜 복잡함 - 프레임워크의 변경에 관계없이 작동하는 방식으로 응용프로그램을 준비하고 있으며, 올바른 방식으로 수행하기 위해 가능한 펑키한 API/프레임워크 내부를 파악할 필요가 없습니다.
• 더 큰 적용 범위 - 느린 요청과 관련된 모든 캐싱 계층을 한 번에 준비합니다.

캐시가 "콜드"가 되는 시기를 설명합니다.

이 문제는 캐시를 적용하는 프레임워크의 모든 계층에서 발생하며 성능 페이지 상단에 적절한 설명이 있습니다.

• 캐시를 오래된 상태로 만드는 잠재적인 변경 후 캐시를 검증해야 할 때마다 시간 초과 또는 더 지능적일 수 있습니다(예: 캐시된 항목의 변경).
• 캐시 항목이 제거될 때 이를 위한 알고리즘은 링크한 성능 기사의 "캐시 제거 알고리즘" 섹션에 설명되어 있지만, 간단히 설명되어 있습니다.
  • LFRU(최소한 자주 사용하지 않음 - 최근에 사용됨) 캐시의 적중 횟수 및 수명은 800개로 제한됩니다.

당신이 언급한 다른 것들, 특히 IIS의 재컴파일과 재시작은 메모리 캐시의 일부 또는 모든 것을 지웁니다.

말씀하신 것처럼 "사전 생성된 보기"를 사용하기만 하면 됩니다.

링크에서 추출됨: "뷰가 생성되면 뷰도 검증됩니다.성능 측면에서 볼 때 뷰 생성 비용의 대부분은 실제로 뷰 검증입니다."

즉, 모델 어셈블리를 빌드할 때 성능 노크가 발생합니다.그러면 컨텍스트 개체는 "콜드 쿼리"를 건너뛰고 컨텍스트 개체 수명 주기 동안은 물론 후속 새 개체 컨텍스트에서도 응답을 유지합니다.

관련 없는 쿼리를 실행하는 것은 시스템 리소스를 사용하는 것 외에는 다른 목적이 없습니다.

바로 가기...

1. 사전 생성된 보기의 추가 작업 모두 건너뛰기
2. 개체 컨텍스트 만들기
3. 그 달콤하고 무관한 질문을 발사합니다.
4. 그런 다음 프로세스가 진행되는 동안 개체 컨텍스트에 대한 참조를 유지합니다(권장하지 않음).

저는 이 틀에 대한 경험이 없습니다.그러나 Solr과 같은 다른 상황에서는 전체 DB(또는 인덱스)를 캐시할 수 없는 한 완전히 더미 읽기는 그다지 유용하지 않습니다.

더 나은 방법은 쿼리를 기록하고 로그에서 가장 일반적인 쿼리를 추출하여 워밍업하는 것입니다.계속하기 전에 준비 쿼리를 로그에 기록하거나 로그에서 제거하지 마십시오.

언급URL : https://stackoverflow.com/questions/13250679/how-to-warm-up-entity-framework-when-does-it-get-cold