Ajax 비새로 고침 페이징을 위한 성능 최적화 방법

이 글은 Ajax non-refresh paging의 성능 최적화 방법에 대한 관련 정보를 주로 소개하고 있으니 필요하신 분들은 참고하시면 됩니다.

Ajax non-refresh paging은 이미 누구에게나 친숙한 페이지일 것입니다. 웹 프런트엔드 페이지.js 메서드에서 Ajax를 통해 서버측 페이징 데이터 인터페이스를 요청하고, 데이터를 가져온 후 다음과 유사하게 페이지에 html 구조를 생성하고 사용자에게 표시합니다.

<script type=”text/javascript”>
function getPage(pageIndex){
ajax({
url:” RemoteInterface.cgi”,
method:”get”,
data:{pageIndex:pageIndex},
callback:callback
});
}
function callback(datalist){
//todo:根据返回的datalist数据创建html结构展现给用户。
}
</script>

그 중 RemoteInterface.cgi는 서버 터미널 인터페이스입니다. 여기서는 공간이 제한되어 있으며 관련 예제 코드는 단지 의미를 명확하게 표현하기 위해 완전하지 않을 수 있습니다.

UI에는 모두에게 친숙한 다양한 스타일의 페이징 컨트롤이 있을 수 있습니다. (pageIndex) here ) 메서드를 사용하는 경우 이 getPage 메서드는 그렇게 간단하지 않을 수 있습니다.

코드 조각 1이 작성된 방식을 따른다면 사용자가 페이지를 넘기기 위해 클릭할 때마다 RemoteInterface.cgi가 한 번 요청될 것이라고 상상할 수 있습니다. 처음을 제외하고 이후에는 데이터 업데이트 가능성을 무시합니다. getPage( 1), getPage(2), getPage(3) 등에 의해 트리거되는 원격 인터페이스 요청과 네트워크를 오가는 데이터 트래픽은 실제로 반복적이고 불필요합니다. 이 데이터는 각 페이지가 처음으로 요청될 때 어떤 형태로든 페이지에 캐시될 수 있습니다. 사용자가 이전에 넘겼던 페이지를 다시 살펴보는 데 관심이 있는 경우 getPage 메소드는 먼저 로컬 캐시에 페이지가 포함되어 있는지 확인해야 합니다. 그렇다면 원격 인터페이스를 호출하는 대신 사용자에게 직접 다시 표시됩니다. 이 아이디어에 따르면 코드 조각 1을 다음과 같이 수정할 수 있습니다.

<script type=”text/javascript”>
var pageDatalist={};
function getPage(pageIndex){
if(pageDatalist[pageIndex]){ //如果本地的数据列表中包含当前请求页码的数据
showPage(pageDatalist[pageIndex])//直接展现当前数据
}
else
{
ajax({
url:” RemoteInterface.cgi”,
method:”get”,
data:{pageIndex:pageIndex},
callback:callback
});
}
}
function callback(pageIndex,datalist){
pageDatalist[pageIndex]= datalist; //缓存数据
showPage(datalist);//展现数据
}
function showPage(datalist){
//todo:根据返回的datalist数据创建html结构展现给用户。
}

</script>

이렇게 하면 네트워크 요청의 왕복 시간이 절약되고 더 중요한 것은 귀중한 네트워크 트래픽을 절약하고 인터페이스에 대한 부담을 줄일 수 있습니다. 섬기는 사람. 네트워크 속도가 낮은 환경이나 인터페이스 서버의 운영 압력이 이미 상대적으로 높은 경우, 이러한 필요한 개선은 분명한 최적화 효과를 보여줄 수 있습니다. 야후의 유명한 34가지 규칙 중 첫 번째는 HTTP 요청 수를 최소화하는 것입니다. Ajax 비동기 요청은 의심할 여지없이 http 요청 범위 내에 있습니다. 트래픽이 적은 웹 애플리케이션이 불필요하게 느껴질 수도 있지만, 하루에 천만 명이 방문하고, 사용자가 평균 5페이지를 넘기며, 한 페이지가 반복해서 조회되는 페이지가 있다고 상상해 보세요. 그런 다음 코드 조각 1이 작성된 방식에 따라 이러한 페이지는 하루 평균 5천만 개의 데이터 요청을 트리거하고 코드 조각 2가 작성된 방식에 따라 하루 평균 최소 1천만 개의 요청을 줄일 수 있습니다. . 1회 요청되는 데이터량이 20kb라면 1,000만 * 20kb = 200,000,000kb, 즉 약 190G의 네트워크 트래픽을 절약할 수 있습니다. 이런 방식으로 절약된 자원은 상당히 상당합니다.

계속해서 더 자세히 알아보고 싶다면 코드 조각 2의 데이터 캐싱 방법에 대해 논의해 볼 가치가 있습니다. 이전에는 페이징 데이터의 적시성을 무시할 수 있다고 가정했지만 실제 애플리케이션에서는 적시성이 피할 수 없는 문제입니다. 캐싱은 의심할 바 없이 적시성 감소로 이어질 것입니다. 실제 캐싱 솔루션은 또한 애플리케이션의 적시성 요구 사항에 대한 분석과 절충에 의존해야 합니다.

일반적으로 적시성을 강조하지 않는 콘텐츠의 경우 페이지 캐싱은 허용됩니다. 첫째, 사용자가 페이지 간에 이동하고 다시 로드하는 경우 업데이트된 콘텐츠를 얻을 수 있습니다. 데이터. 또한, 사용자가 페이지를 새로 고치는 습관이 있는 경우, 특히 목록에 데이터 업데이트가 있는지 확인하고 싶을 때 페이지를 새로 고치도록 선택할 수 있습니다. 완벽함을 추구한다면 5분 등의 시간 범위를 설정하는 것도 고려해 볼 수 있습니다. 사용자가 현재 페이지에 5분 이상 머물렀다면 5분 이내에 페이지를 넘기면 먼저 페이지의 캐시를 읽고, 5분 후에 페이지를 넘기면 서버 데이터를 다시 요청하게 됩니다.

경우에 따라 데이터 업데이트 일수 등 데이터 업데이트 빈도를 예측할 수 있다면 로컬 저장소를 사용하여 일정 기간 후에 서버 데이터 요청을 트리거하는 것도 고려할 수 있습니다. 요청 수와 트래픽에 더 나은 영향을 미칠 것입니다. 물론 어떤 캐싱 방식이 적합한지는 궁극적으로 제품의 적시성 요구 사항에 따라 다르지만, 특히 방문 횟수가 많은 페이지의 경우 요청과 트래픽을 최대한 줄이는 것이 원칙입니다.

적시성 요구 사항이 높은 데이터 유형의 경우 캐싱이 전혀 부적절하지 않습니까? 물론 그렇지는 않지만 전반적인 아이디어가 바뀌어야 합니다. 일반적으로 소위 변경이란 주로 목록의 데이터가 증가, 감소 또는 변경되었지만 대부분의 데이터는 변경되지 않았음을 의미할 수 있습니다. 대부분의 경우 위에서 언급한 설정은 일정 기간 동안 캐싱에 계속 적용됩니다.

데이터의 실시간 업데이트에 가까운 요구 사항이 있는 경우 20초마다 getPage(pageIndex) 메서드를 실행하고 목록을 다시 그리는 등 타이머를 사용하는 것을 쉽게 생각할 수 있습니다. 그러나 1,000만 페이지 방문이라는 이전 가정을 생각하는 한 이는 의심할 여지 없이 매우 무서운 일이라는 것을 알게 될 것입니다. 이 방문 수와 재시도 빈도로 인해 서버는 큰 압박을 받고 있습니다. 이 상황을 어떻게 처리할지에 대해서는 Gmail, 163 Mailbox 및 Sina Mailbox가 메일링 리스트 페이지를 어떻게 처리하는지 살펴보시기 바랍니다. 이는 매우 큰 일일 방문 수, 데이터 요구 사항의 실시간 업데이트 등 이전 가정을 거의 동시에 충족합니다. 네트워크 패킷 캡처 도구로 분석해 보면 사용자가 동일한 페이지 번호에 대해 반복적으로 데이터를 요청할 때 서버에 요청을 하지 않는다는 것을 알아내는 것은 어렵지 않습니다. 메시지 업데이트 시 사용자에게 적시에 알림을 보내고 메일링 목록이 업데이트되도록 하기 위해 예약되고 반복되는 비동기 요청을 사용할 수 있지만 이 요청은 목록을 새로 고치는 대신 상태 쿼리만 수행합니다. 메시지 업데이트가 있는 상태를 얻은 경우에만 업데이트된 데이터를 얻기 위한 요청이 시작되거나, 업데이트가 발견되면 상태 쿼리 인터페이스가 업데이트된 데이터를 직접 반환합니다. 실제로 163개의 메일함의 정기적인 상태 쿼리 간격은 2분에 한 번 정도로 비교적 길게 설정되어 있습니다. 요청 수. 그러나 이러한 처리 방법은 프런트엔드만으로는 불가능할 수 있으며, 백엔드 인터페이스와 함께 구현 계획을 전체적으로 고려해야 합니다.

이제 다시 돌아가서 코드 2의 데이터 캐싱 방법을 살펴보겠습니다. 이제 더 이상 요청 수와 트래픽 절감에 대해 논의하지 않고, 살펴볼 가치가 있는 것이 있는지 알아보기 위해 프런트 엔드 구현을 살펴보겠습니다. 코드 2에 표시된 처리 방법에 따라 원래 데이터가 저장됩니다. 다시 호출할 때 showPage(datalist)는 사용자에게 표시하기 위해 데이터를 기반으로 다시 html 구조를 재구성해야 하지만 우리는 이러한 생성 과정을 수행했습니다. , 처음으로 구조를 생성할 때 구조를 직접 저장하는 것을 고려할 수 있습니까? 이렇게 하면 js의 반복 계산을 줄일 수 있으며, 특히 구조가 더 복잡할 경우 고려해 볼 가치가 있습니다. 다시 생각해 보세요, 이 구조는 이전에 페이지를 넘길 때 파괴하고 새로운 구조를 생성하는 것도 리소스를 소모합니다. 처음 생성하고 페이지를 넘길 때 파괴하지 않을 수 있습니까? . CSS 스타일을 제어하여 숨깁니다. 페이지를 반복적으로 넘기면 생성된 구조 사이에서 서로 표시하거나 숨기는 것만 제어할 수 있습니다.

마지막으로 여기서 설명하는 방법은 모든 시나리오에 적용할 수는 없지만 영감을 줄 수 있다면 적절한 시기에 한두 가지를 시도해 볼 수 있습니다. 동시에 아이디어가 확산된다면 Refresh-Free 페이징에만 적용되지 않을 수도 있습니다. 여기서 함께 논의해 봅시다.

위 내용은 모두를 위해 제가 정리한 내용입니다. 앞으로 모든 사람에게 도움이 되기를 바랍니다.

관련글 :

firefox 기반 Ajax 이미지 업로드

Ajax 로딩 외부 페이지 팝업 레이어 효과 구현 방법

Ajax 크로스 도메인(기본 도메인 이름 동일) 양식 제출 방법

위 내용은 Ajax 비새로 고침 페이징을 위한 성능 최적화 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!