글로벌 사이트 퍼포먼스를 위해 작은 Ajax 요청이 많거나 큰 요청이 많습니까?

글로벌 사이트 퍼포먼스를 위해 작은 Ajax 요청이 많거나 큰 요청이 많습니까?

제목, URL, 날짜 및 카테고리와 함께 게시물 목록을 반환하는 Ajax 검색 필드가 있는 워드프레스 사이트가 있습니다.

매회 최대 10개의 결과가 표시되도록 결과에 페이지 번호를 매기고 싶습니다.

궁금한 점은 페이지를 넘길 때마다 다른 요청을 하는 것이 좋은가, 아니면 한 번만 요청을 해서 모든 투고를 가져온 후 javascript(응답은 i JSON)로 페이지 매칭을 관리하는 것이 좋은가?

작은 요청은 가벼운 응답과 큰 응답 중 어느 쪽이 더 자주 하는 것이 좋습니까?

사이트 라이프 초기에는 첫 번째 솔루션이 최선이라고 생각합니다.사이트 확장에 따른 확장성은 잘 모르겠습니다.

당신은 어떻게 생각하나요?

업데이트: 몇 가지 매우 좋은 답변을 받았습니다.문제의 사용자 인터페이스 측면에서의 대처가 더 많았습니다.

Hwr 퍼포먼스 관점에 좀 더 집중해 주셨으면 합니다.내 사이트는 공유 서버에 있지만, 이 사이트는 국제적으로 노출되기 때문에 트래픽이 빠르게 증가할 것으로 예상됩니다.제가 우려하는 것은 워드프레스가 에이잭스 요청으로 인한 오버헤드에 대처할 수 없다는 것입니다.

그럼 다시 질문으로 돌아가서 서버의 총 부하, 많은 작은 요구, 요청된 결과 페이지만 로드하는 것과 모든 결과가 포함된 큰 페이지 중 어느 것이 더 좋을까요?

모든 사용자가 모든 결과 페이지를 체크하지는 않을 것으로 생각됩니다만, 첫 번째 결과 페이지는...

정답은 "에 따라 다르다"입니다.

이미 알려진 수량(페이지당 10개의 결과, 10페이지의 결과)을 모두 사용자가 사용할 수 있도록 하려면 가능한 한 빨리 500ms 타이머로 청크(10 또는 20)를 다운로드하는 것이 좋습니다.

그런 다음 추가 백 페이지를 비동기적으로 채우고 그에 따라 "전체 페이지" 컨트롤을 업데이트할 수 있습니다.

그 후 사용자는 즉시 결과를 얻을 수 있으며 모든 데이터를 2초 만에 왔다 갔다 할 수 있습니다.

모든 데이터에 즉시 액세스해야 하는 사이트가 있고 40개의 결과를 표시해야 하는 경우에는 대규모 덤프를 사용하십시오.

무한 스크롤 사이트가 있는 경우 페이지 길이를 몇 개 가져와야 합니다.Twitter 등의 경우, 컨테이너의 평균 높이와 화면 높이를 미리 계산해 둡니다.그리고 나서 나는 3-4개의 스크린 길이의 트윗을 다운받습니다.그 후 사용자가 두 번째 또는 세 번째 화면(또는 세 번째 또는 네 번째 화면)으로 스크롤 할 때 다음 배지를 다운로드 합니다.

할 수 후 이상 임), 의 총 합니다).부를 확인합니다(마지막 실행 후 16밀리초 이상 경과한 경우(분명히 스크롤 중임), 화면 높이 및 마지막 배치의 총 높이(전체 높이)를 고려하여 현재 위치를 확인합니다.screen_bottom >= latest_batch.height * 0.75와 유사합니다 또는 이와 유사합니다.즉, screen_bottom은 last_batch가 .사용자가 위쪽으로 스크롤하면 이전 배치보다 높은 screen_bottom은 완전히 음수가 됩니다.

...아니면 정상화시켜서 백분율만 처리하도록 할 수도 있습니다.

데이터가 항상 존재하는 것처럼 느껴지기에 충분합니다.처음부터 큰 블록이 로드될 때까지 기다릴 필요는 없지만 이동 중에 작은 블록이 로드될 때까지 기다릴 필요도 없습니다.

따라서 현재 수행 중인 작업 및 사용자가 데이터를 어떻게 사용할 것으로 예상하는지에 따라 최적의 매개체가 무엇인지 파악하십시오.

이 결정에는 사용자가 사이트와 대화하는 방법(예: 사용자가 보는 결과 수와 쿼리 방법)과 "평균 검색 결과"의 크기가 얼마나 되는지 등 두 가지 요소가 있습니다.수천 개의 투고와 일반적인 검색어가 있는 경우, "대규모"의 검색어를 사용하면 매우 큰 결과 세트를 얻을 수 있습니다.사용자가 이 정보를 많이 참조하는 경향이 있는 경우, 페이지를 로드할 때마다 요청을 하면 많은 요청이 발생합니다.

일반적인 답변은 없습니다. 이는 응용 프로그램과 사용자의 검색 패턴에 따라 크게 달라집니다.일반적으로 작업을 수행하는 가장 간단한 작업을 수행할 뿐만 아니라 사용자 상호 작용(쿼리 및 결과 크기 로깅 등), 사이트 성능(예: Google Analytics 로드 시간) 및 서버 로드(예: munin 경유)도 모니터링합니다.문제가 발생했을 경우, 이 시점부터 애플리케이션을 최적화할 수 있습니다.그 시점까지, 유저와 애플리케이션에 대한 이해가 한층 더 깊어집니다.

뭐, 일단은.AJAX가 일반 페이지 로드에서 작성된 것과 동일한 게시물을 작성하는 경우 페이지 로드를 시뮬레이션할 수 있습니다.즉, 다수의 투고(투고가 많은 페이지 등)를 쿼리하고, 그 모든 데이터를 JS에 송신해, 페이지 번호 매김을 실시합니다.

물론 한 번에 모든 투고를 보낼 수는 없기 때문에 몇 페이지나 이용할 수 있는지 처리하셔야 합니다.그렇기 때문에 한 번에 한 페이지 분량씩 문의하는 것이 좋다고 생각합니다.또, 통상의 WP 동작은, 투고 ID를 반환하는 쿼리를 작성하고, 페이지의 투고 마다 투고 전체에 쿼리를 작성하는 것에 주의해 주세요.

사이트를 최적화하려면 캐시 플러그인을 설치하십시오.모든 DB 쿼리를 HD로 캐시한 다음 동일한 쿼리를 다시 작성하는 대신 이러한 파일을 사용합니다.

저는 asjst를 만들었는데, 디바이스의 업로드 속도 때문에 다운로드가 훨씬 빠르지만 리소스 요청은 느리다는 것을 알게 되었습니다.

대량 업로드가 잘못되었습니다.

위의 스크린샷에서 볼 수 있듯이 업로드되는 바이트 수는 많고 다운로드되는 바이트 수는 적습니다.

일반적으로 다운로드가 업로드보다 빠릅니다.

나도 비슷한 상황에 처했다.서버에 액세스할 수 없으며 Sharepoint에 Excel에서 .xlsb 형식으로 파일을 저장해야 합니다.커스텀 바이너리 ajaxTransport를 사용하여 어레이버퍼로 되돌린 후 스레드를 사용합니다.JS는 개별 스레드의 버퍼를 처리하여 SheetsJ를 통해 사용 가능한 JSON 데이터를 얻은 후 이를 단일 JSON 데이터 배열로 병합합니다.

테스트 결과, 하나의 대용량 파일이 처리되는 데 41초, 4개의 작은 파일이 28초, 8개의 작은 파일이 약 20초, 16개의 작은 파일이 처리되는 데 20초가 걸렸습니다.

따라서 파일이 작아질수록 AJAX 요청 수가 증가하여 파일 처리 시간이 단축되는 경우 수익률이 감소합니다.솔직히 말하면 스레드를 사용하는 경우와 사용하지 않는 경우의 실제 속도 향상은 보이지 않습니다.AJAX 콜의 비동기 특성으로 인해 콜이 시작되고 종료되는 시점 사이에 처리가 가능하거나 큰 차이를 인식할 수 있을 만큼 처리되지 않은 경우가 있습니다.하지만 스레드 버전에서는 페이지가 허용됩니다.로더로 데이터를 로딩하는 동안 정지하지 않도록 하는 것이 장점이라고 생각합니다.

언급URL : https://stackoverflow.com/questions/12200973/better-many-small-ajax-request-or-a-big-one-for-global-site-performance