일부 세부 사항; IIS와 동일한 컴퓨터에서 AppFabric 1.1의 바닐라 구성을 실행하고 있습니다. AppFabrics의 로컬 캐시를 사용하도록 설정하지 않았습니다.이 로컬 캐시 경계 외부의 성능에 관심이 있습니다.AppFabric 캐싱 - 엄청나게 느리거나 잘못 구성 되었습니까?
분명히 httpruntime 캐시와 같은 in-proc 캐싱은 매우 빠르다. 사실 그것은 약 14,000 개의 레코드를 포함하고있는 테스트중인 데이터 세트를 검색 할 수 있으며 10 밀리 초 미만의 데이터로 약 25MB가 직렬화됩니다.
그러나 앱 패브릭에서 같은 양의 데이터를 검색하는 데는 약 9 초가 걸립니다. 분명히 이것은 엄청난 차이이며 내가 이것을 어떤 종류의 대체물로도 사용할 수 없기 때문에 (나는 비밀리에 내가 그것을 할 수 있기를 바랬다).
이 성능은 올바르게 적용됩니까? 메신저에 누락 된 부분이 있습니까?
....
첫째, 같은 일을 비교되지 않은 : 당신이 뭔가 httpRuntime을 캐시를 얻을 때, 당신은 메모리의 초기 항목에 대한 참조를 얻고있다. 일부 코드가이 항목을 수정하면 다른 모든 사용자/스레드에 변경 사항이 표시됩니다. 그래서 로컬 캐시에 모든 것을 복제하는 것이 좋습니다.
AppFabric 캐시는 웹 팜용으로 설계 되었기 때문에 호스트가 같은 컴퓨터에 있어도 개체를 네트워크를 통해 보내야하기 때문에이 작업을 수행 할 수 없습니다. 따라서 데이터 항목은 NetDataContractSerializer를 사용하여 직렬화됩니다.
AppFabric은 단순히이를 위해 설계되지 않았기 때문에 HttpRuntime보다 빠르지 않습니다. WebFarm과 대량의 데이터를 위해 설계되었으므로 응용 프로그램의 안정성, 확장 성 및 성능이 향상됩니다.
예를 들어, 우리 회사에서는 몇 년 전에 HttpRuntime Cache 만 사용했습니다. AppFabric은 DB 부하를 줄이고 웹 응용 프로그램 성능 (캐시 클러스터에서 가져온 항목이며 DB에서로드하지 않은 항목)을 향상시키는 완벽한 솔루션입니다. 30 개 이상의 서버가 있고 데이터베이스가 오버로드되어 있기 때문에 이제는 완전히 불가능합니다.
서버가 하나뿐이라면 AppFabric을 사용하면 어떤 이점도 얻지 못할 것입니다. 또한 전용 캐시 호스트가 권장됩니다.
결국 14000의 데이터 세트가 최적이 아니기 때문에 개체에 할 일이있을 것이라고 확신합니다!
이 질문이 몇 가지 구체적인 답변으로 이어지기를 바란다는 것과 똑같은 문제가 있습니다. – Scott