WSAPI가 더 큰 최대 페이지 크기를 허용하면 정말 좋을 것입니다. 몇 천 개의 작업 항목을 가져 오는 경우가 많이 있으며 레코드의 한 필드 만 필요합니다. 한 번에 200 개의 레코드를 가져 오면 사용자의 대기 시간이 길어지고 수백 개의 개별 페이지가로드됩니다.WSAPI 최대 페이지 크기
LBAPI 페이지 크기는 이것이 확실히 가능하다는 표시입니다. 최대 페이지 크기 (정확히 기억한다면)는 10,000입니다. 레코드 당 정보량이 적다는 것을 알았지 만 (전체 개체 대신 OID) 대역폭에 대한 WSAPI의 최적화 (전체 채우기 세부 정보를 반환하지 않음)는 200보다 현저히 낮습니다.
여기에는 속도 저하에 기여하는 두 가지 문제가 있습니다. 첫 번째는 작은 페이지 크기입니다. 이 문제를 현재 1000 번으로 돌리는 내부 토론이 있습니다 (특히 v2.0에서는 요청이 반환되지 않습니다).
두 번째는 WsapiDataStore가 순차적으로 페이징을 수행한다는 것입니다. 첫 번째 페이지는 항상 순차적으로로드해야하지만 나머지 페이지는 병렬로 수행 할 수 있어야합니다.
곧 해결 될 두 번째 항목을 추적하는 데 결함이 있습니다. 바라건대 첫 번째 항목에 대해서도주의를 기울여야합니다.
Kyle에게 회신 해 주셔서 감사합니다. 그래서, 페이지 크기를 늘리는 데에 효과가있는 것처럼 보이지만, 여러분이 1000을 넘는 것을 막는 것은 무엇입니까? –
우리는 아직 모릅니다. 주로 우선 순위 할당 문제입니다. 부하 테스트 환경에서 이러한 변화를 모델링하고 다양한 시나리오를 측정해야합니다. –
WsapiDataStore 설정에서'limit : Infinity'를 사용 했습니까? –
있습니다. 결과는 한 번에 한 페이지 씩로드됩니다. 네트워크 활동을 보면 각 요청이 순차적으로 처리되는 것을 볼 수 있습니다. WSAPI를 사용하여 큰 쿼리를 처리하는 가장 빠른 방법은 많은 페이지를 찾아서 저장소의 각 페이지에 대해 "loadPage (##)"를 실행하는 것입니다 (모든 쿼리를 한 번에 실행 함).) 모든 레코드가 반환되면 레코드를 그룹화하십시오. 이로 인해 150 개 이상의 요청이 동시에 처리되는 경우 몇 가지 문제가 발생할 수 있습니다. haha –
저는 여러 프로젝트에서 성공한 Infinity 제한을 사용할 수있었습니다. (2.0rc1) 나는 당신이있는 데이터의 볼륨을 당기지 않을 수도 있도록 약 1,000 항목을로드 중입니다. – amcolosk