엔터티 프레임 워크를 "웜업"하는 방법?

엔터티 프레임 워크를 "웜업"하는 방법? 언제 "감기"를 얻습니까?

---

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

머리말:

나는 최근에 Entity Framework에 대해 많은 연구를 해 왔으며 쿼리를 워밍업하지 않을 때의 콜드 쿼리 (cold query)라는 성능이 나를 귀찮게합니다.

Entity Framework 5.0 의 성능 고려 사항 기사를 살펴 보았습니다. 저자는 Warm 및 Cold 쿼리 의 개념 과 그 차이점에 대해 소개했습니다 . 여기에 6 개월의 경험 만 남았다 고 언급 할 가치가 있습니다.

이제 성능 측면에서 프레임 워크를 더 잘 이해하려면 추가로 조사 할 수있는 주제를 알고 있습니다. 불행히도 인터넷에있는 대부분의 정보는 구식이거나 주관적으로 부풀어 있으므로 Warm vs Cold 쿼리 주제 에 대한 추가 정보를 찾을 수 없습니다 .

기본적으로 지금까지 주목 한 것은 재 컴파일 또는 재활용 적중 시마다 초기 쿼리 속도가 매우 느려진다는 것입니다. 모든 후속 데이터 읽기는 예상대로 빠릅니다 ( 주관적 ).

우리는 Windows Server 2012, IIS8 및 SQL Server 2012로 마이그레이션 할 예정이며, 주니어로서 실제로 나머지 전에 테스트 할 기회를 얻었습니다. 나는 그들이 첫 번째 요청을 위해 내 응용 프로그램을 준비시킬 워밍업 모듈을 소개하게되어 매우 기쁩니다. 그러나 Entity Framework 워밍업을 진행하는 방법을 잘 모르겠습니다.

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

• 제안 된대로 미리보기를 생성하십시오.
• 결국 내 모델을 별도의 어셈블리로 옮깁니다.

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

• 응용 프로그램 시작시 더미 데이터 읽기를 수행하여 모델을 예열하고 생성하고 유효성을 검사합니다.

질문 :

• 언제든지 Entity Framework에서 고 가용성을 유지하는 가장 좋은 방법은 무엇입니까?
• 어떤 경우에 Entity Framework가 다시 "감기"됩니까? (재 컴파일, 재활용, IIS 재시작 등)

---

• 언제든지 Entity Framework에서 고 가용성을 유지하는 가장 좋은 방법은 무엇입니까?

미리 생성 된 뷰와 정적 컴파일 된 쿼리를 혼합하여 사용할 수 있습니다.

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

미리 생성 한 뷰는 언급 한 다른 가능성입니다. 특히 컴파일하는 데 시간이 오래 걸리고 변경되지 않는 쿼리의 경우. 그렇게하면 런타임에서 컴파일 시간으로 성능 오버 헤드를 옮길 수 있습니다. 또한 이것은 지연을 유발하지 않습니다. 그러나 물론이 변경은 데이터베이스에 적용되므로 다루기가 쉽지 않습니다. 코드가 더 유연합니다.

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

단일 컨텍스트를 오랫동안 유지하지 마십시오. 각 컨텍스트 인스턴스에는 자체의 첫 번째 레벨 캐시가 있으므로 커질수록 성능이 저하됩니다. 컨텍스트 작성은 저렴하지만 컨텍스트의 캐시 된 엔티티 내부의 상태 관리는 비용이 많이들 수 있습니다. 다른 캐시 (쿼리 계획 및 메타 데이터)는 컨텍스트간에 공유되며 AppDomain과 함께 종료됩니다.

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

• 어떤 경우에 Entity Framework가 다시 "감기"됩니까? (재 컴파일, 재활용, IIS 재시작 등)

기본적으로 AppDomain을 잃을 때마다. IIS는 29 시간 마다 재시작을 수행 하므로 인스턴스가 보장되지 않습니다. 또한 활동이없는 시간이 지나면 AppDomain도 종료됩니다. 다시 빨리 올라 오려고 시도해야합니다. 어쩌면 일부 초기화를 비동기 적으로 수행 할 수도 있습니다 (그러나 멀티 스레딩 문제는 조심하십시오). AppDomain의 종료를 막기위한 요청이 없지만 결국에는 애플리케이션에서 더미 페이지를 호출하는 예약 된 작업을 사용할 수 있습니다.

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

---

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

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

---

일반적인 팁.

• 액세스 한 내용 과 요청 시간을 포함하여 엄격한 로깅을 수행 합니다 .
• 응용 프로그램을 초기화 할 때 더미 요청을 수행 하여 이전 단계에서 가져온 매우 느린 요청 을 웜 부팅 합니다.
• 실제 문제가 아닌 한 최적화를 방해하지 말고 응용 프로그램 소비자와 의사 소통하고 묻습니다. 최적화가 필요한 것을 파악하기 위해서만 지속적인 피드백 루프를 유지하십시오 .

이제 왜 더미 요청이 잘못된 접근법 이 아닌지 설명해 보자 .

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

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

이는 캐시를 적용하는 프레임 워크의 모든 계층에서 발생하며 성능 페이지 맨 위에 좋은 설명이 있습니다.

• 캐시를 무효로 만드는 잠재적 변경 이후 캐시를 검증해야하는 경우, 이는 시간 초과 또는보다 지능적 일 수 있습니다 (예 : 캐시 된 항목의 변경).
• 캐시 항목이 제거 될 때이를 수행하는 알고리즘은 연결 한 성능 문서의 "캐시 제거 알고리즘"섹션에 설명되어 있지만 짧게 설명되어 있습니다.
  • LFRU (최소-최근에 가장 최근에 사용 된)는 항목 수와 기간에 800 개 항목으로 제한됩니다.

언급 한 다른 것, 특히 IIS를 다시 컴파일하고 다시 시작하면 메모리 캐시의 일부 또는 전부가 지워집니다.

---

As you have stated, use "pre-generated views" that's really all you need to do.

Extracted from your link: "When views are generated, they are also validated. From a performance standpoint, the vast majority of the cost of view generation is actually the validation of the views"

This means the performance knock will take place when you build your model assembly. Your context object will then skip the "cold query" and stay responsive for the duration of the context object life cycle as well as subsequent new object contexts.

Executing irrelevant queries will serve no other purpose than to consume system resources.

The shortcut ...

1. Skip all that extra work of pre-generated views
2. Create your object context
3. Fire off that sweet irrelevant query
4. Then just keep a reference to your object context for the duration of your process (not recommended).

---

I have no experience in this framework. But in other contexts, e.g. Solr, completely dummy reads will not be of much use unless you can cache the whole DB (or index).

A better approach would be to log the queries, extract the most common ones out of the logs and use them to warm up. Just be sure not to log the warm up queries or remove them from the logs before proceeding.

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