2010-06-05 6 views
0

저는 (50ms마다) 끊임없이 필요하고 MVC 작업을 호출하고 데이터를 수집/제거해야하는 애플리케이션이 있습니다.Linq to SQL 및 실시간 데이터

Linq는 SQL과 MVC를 구현하는 방법이 단순하기 때문에 Linq를 사용하고 있습니다. 성능면에서 완벽하지는 않지만 비교적 잘 작동하지만 가장 빠른 속도는 얻을 수 있습니다. 내 현재 접근 방식은 200ms입니다 (요청 중복 없음).

사이트를 호출 할 때마다 datacontext의 새 인스턴스가 만들어지고 쿼리/삽입되어 해당 데이터가 반환됩니다.

datacontext를 정적으로 유지하는 방법이 있습니까?하지만 submitchanges는 매 5 초마다 이렇게 말합니다. 따라서 데이터의 메모리 버전을 사용하는 것이 좋습니다.

편집 : 나는 모두 같은 특성과 내 컨텍스트의 객체를 포함하는 완전 분리 구조를 구축, 그리고 정적 위해 Application_Start()에 해당 개체를 선언, 모든 X 요청에

는 스레드가 연결 해제 된 모든 오브젝트를 첨부하여 데이터베이스에 저장하십시오.

이 성공적으로 내 왕복 시간 만이 100ms, 큰 개선을 감소했지만, 그것은 내가의 수준을 얻고있다 "실시간"

이 될 필요가 무엇에서 부족 창턱 마이크로 최적화,하지만 나는 그것을 더 빨리 밀어 수없는 것.

답변

1

DataContext은 데이터베이스에 갈 때마다 만들어집니다. 병목 현상이 없어야합니다.

값 비싼 데이터베이스 연결 생성이 염려되는 경우 문제가되지 않을 수 있습니다. 작은 연결 폴링이 있으므로 연결은 후속 호출에 의해 재사용됩니다.

성능을 향상시키기 위해 수행 할 수있는 작업 (현재 단어가 들리지는 못했습니다)은 자동 생성 된 SQL을 저장 프로 시저로 바꾸는 것입니다. 실행 계획 재창조에 약간의 시간을 절약 할 수 있습니다.

0

성능 향상에 도움이 될 수 있습니다. 그러나 고전적인 ADO.NET보다 결코 빠를 수 없습니다. 성능이 주요 관심사라면 모든 ORM은 매우 나쁜 선택입니다.

최적의 성능을 얻으려면 언제든지 이들을 혼합 할 수 있습니다 (Linq2SQL + ADO.NET).

0

LINQ 컨텍스트/쿼리를 만드는 것이 병목 현상이라고 생각하지 않습니다. ORM과 마찬가지로 사용하는 데 약간의 오버 헤드가 있지만, 많은 컨텍스트와 복잡한 쿼리 트리를 만들지 않는 한 중요한 것은 아닙니다.

내 생각 엔 LINQ가 예상 한 쿼리를 생성하지 않는 것 같습니다. 조심하지 않으면 많은 쿼리를 생성 할 수 있으며 여러 테이블에서 가져 오기를 시도합니다. 당신은 당신이 당신은 또한 당신의 쿼리를 사용해 우수한 LINQPad을 사용할 수 있습니다

context.Log = Console.Out; // Or some other stream 

을 사용할 수 있습니다 실행 쿼리 무엇을 찾으려면. 이것이 문제가 아니라면 프로파일 러를 사용하여 코드를 프로파일해야합니다. 나는 개인적으로 dotTrace을 좋아합니다.