나는 약 1 만명의 사용자와 웹 응용 프로그램이 있습니다. 해당 응용 프로그램의 거의 모든 웹 페이지는 GetUser() 메서드를 호출하여 (활동 스트림의 이름과 기타 사용자 정보를로드합니다). 지금은 각 호출에 대해 데이터베이스를 때리고, 메모리에있는 모든 사용자를 캐싱하고 Linq를 사용하여 검색 결과 또는 GetUser()를 가져 오는 것을 생각하고 있습니다.
내 유일한 문제는 메모리에있는 모든 사용자를 캐싱하는 것이 좋습니다. 내 RAM을 낭비하고 싶니? 개인적으로 RAM에서 가져 오는 것이 DB에서 가져 오는 것보다 훨씬 빠르다고 생각합니다 (DB가 최적화되고 인덱싱 되더라도).
캐시 유효성 검사/업데이트/등을 이미 처리했음을 유의하십시오.
stackoverflow는 모든 사용자를 캐시합니까?
우리는 비슷한 것을했지만 Linq를 사용하는 대신 각 웹 서버에 SQL Server Express 복사본을 설치했습니다. 우리는 사용자 데이터 변경을 각 웹 서버로 푸시하고 로컬 응용 프로그램은 미들 티어를 사용하여 로컬 데이터베이스에서 데이터를 주기적으로 만 가져오고있었습니다 (하지만 최소한 데이터베이스를 사용하는 모든 사용자가 아닌 로컬이었습니다).
캐싱에 사용하는 기술과 응용 프로그램 (또는 Linq)이 로컬 복사본을 새로 고치는시기를 알고있는 방법은 캐시 된 데이터가 얼마나 오래된 것인지에 따라 다릅니다.
업데이트 등에서 발생하는 이벤트를 사용하여 캐시를 동적으로 업데이트합니다. 캐싱을 위해 우리는 in-memory .NET 캐쉬 객체를 사용합니다. –
명백히 뒷걸음질 치기 -하지만이 경우 캐시 서버를 사용하면 더 나아지지 않습니까? –
@Stuart 어쩌면? 이것은 redis/memcached 등이 실제로 성숙되기 전에 2000 년대에 다시 돌아 왔습니다. 오늘날에도 팀은 구현/상호 작용할 새로운 기술을 배우지 않아도되므로 로컬 DB 접근 방식을 선택할 수 있습니다. 둘 다 기본 데이터베이스 서버의 자원 대신 응용 프로그램 서버의 메모리를 계속 사용합니다. –
GetUser가 대부분 동일한 시간대의 사용자를 반환하고 대부분의 사용자가 거의 검색되지 않는 경우 하이브리드 방식으로 사전 (또는 다른 모음)을 설정하고 해당 모음을 검사 할 수 있습니다 먼저 존재하지 않으며 데이터베이스에서 가져 와서 콜렉션에 저장하십시오.
이 접근법을 사용하면 이미 부적절한 자체 메커니즘을 가지고 있기 때문에 캐시를 사용할 수도 있습니다.
이렇게 말한 후에 나는 사용자를 위해 똑같은 일을 한 프로젝트에서 일했습니다 (우리는 약 100 명의 사용자 만있었습니다). 우리의 모든 조사와 테스트 결과 매번 데이터베이스로가는 것이 더 빠르다는 것을 알았습니다.
자주 사용하는 사용자가 자주 로그인하지 않는 사용자보다 컬렉션에있을 가능성이 높아지도록 일부 조건을 컬렉션에 추가 할 수도 있습니다 – Gisli
웹 팜입니까? – Paparazzi
http://stackoverflow.com/questions/11124273/linq-performance-for-in-memory-collection/11124548#11124548 –
사용자 데이터의 양은 어느 정도입니까? 사용자 이름과 몇 가지 다른 필드 일 경우이를 인증 쿠키로 직렬화 한 다음 필요한 경우 DB에서 전체 사용자 데이터를로드하는 것을 고려할 수 있습니다. – Nathan