대역폭을 절약하기 위해 여러 HTTP 요청을 병합하는 것이 좋습니까?

느린 모바일 연결에서 가끔 사용되는 단일 페이지 응용 프로그램을 준비 중입니다. 일부는 API 요청 측면에서 상당히 무겁습니다 (새 화면 표시를 위해 10 개의 서로 다른 리소스 가져 오기).

이제 이러한 서비스를 필요한 모든 데이터를 제공하지만 REST 원칙 측면에서 "순수하지 않은"서비스로 병합하는 것이 좋습니다. 상당한 성능 향상이 예상됩니까?

REST의 장점 중 하나는 기존 http 캐시를 통해 요청을 캐시 할 수 있다는 것입니다 (캐시 가능한 요청이라고 가정).

단일, 더 크거나 덜 자주 사용되는 다른 요청 a,b,c,d이있는 경우 (이번에는 항목을 가져오고 다음에 항목을 가져올 예정 a,b,d,e임) 요청이 캐시 누락 일 가능성이 높고 캐시에서 만료 될 수 있습니다. 당신과 소스 사이 어딘가에 앉아.

위에서 언급 한 두 세트의 요청을 고려할 때, 두 번째 요청은 75 % 캐시 적중률을 가질 수 있으며 e네 가지 모두가 아니라 실제로 페치 속도가 훨씬 빠릅니다 .

이는 캐시 미스 요청의 첫 번째 세트를 수행하는 사람이 여전히 캐시 미스를 갖기 때문에이를 사용하는 사람들에게는 즉시 명백하지 않을 수 있습니다.

이것은 로컬이 아닌 캐시 적중을 얻을 가능성이 적은 모바일 네트워크 연결에 이상적이라고 말할 수는 없습니다. 그러나 핫스팟 또는 기타 Wi-Fi 상황의 경우 캐시 적중이 훨씬 더 유용 할 수 있습니다.

이 중 많은 부분이 응용 프로그램 작동 방식에 따라 다릅니다. 시작할 때이 모든 데이터를 요구합니까? 또는 응답 시간 예상이 다른 페이지로드에 대해 이야기하고 있습니까?

이상적인 상황은이를 테스트하여 다양한 상황에서 응용 프로그램이 어떻게 수행되는지 확인하는 것입니다. 모바일 장치를 모니터링 할 수 있는 로컬 Wi-Fi 네트워크 (Google의 첫 번째 히트)에 바인딩 한 상황을 설정하고 인터넷 연결 상태 를 시뮬레이션하여 실제로 작동하는 방식 (또는 작동하지 않는 방식)을 고려하십시오. 어느 것이 가장 성능이 좋습니까?

직감은 다소 정확합니다. 요청을 크게하는 것이 확실히 바람직합니다. 청키 한 API가 더 나은 경향이 있습니다. 특히 아무것도 볼 수 없기 때문에 일부 작업을 볼 수 있고 일부는 악몽 같은 대체 시나리오를 작성하지 못하는 드문 드문 연결성을 사용합니다.

한 가지 큰 경고가 있습니다. 너무 퉁퉁 불퉁하고 전화와 응답이 부풀어 오릅니다. 예를 들어, 처음 페이지를 방문한 다음 데이터를 원할 때마다 큰 페이지를 새로 고치지 않고 업데이트 스트림을 작은 비트 단위로 호출하는 것이 좋습니다.

또는 모든 가능성에서 두 가지 방법을 모두 원할 것입니다.

이 Dropbox 기술 블로그 기사를 확인 하십시오 .

여기에서 모든 사진의 썸네일을 검색하기 위해 제안한 솔루션을 왜 그리고 어떻게 구현했는지 자세히 설명합니다. 문제를 해결할만한 가치가 있는지 알아보기 위해 성능을 측정한다고합니다.

짧은 요약:

Dropbox 웹 사이트는 수백 개의 썸네일을로드해야합니다. 일부 브라우저의 제한 사항으로 인해 모든 썸네일이 병렬로로드되는 것은 아닙니다 (요청이 대기 중). 그들은 SPDY 를 사용하고 싶었지만 시스템의 일부가 아직 그것을 지원하지 않기 때문에 사용할 수 없었습니다. 결국 HTTP를 통한 일괄 요청을 사용하여 응답 당 여러 축소판을 압축 형식으로 반환합니다. 결과에 따라 전체 페이지로드 시간이 40 % 향상되었습니다.

요컨대, 귀하의 접근 방식은 다소 정확하며 래퍼 서비스의 혜택을 누릴 수 있습니다.

이 서비스는 기존 단일 호출을 하나의 서비스 측 방법으로 결합합니다. 이를 위해 클라이언트에서 서비스 측으로의 통화를 결합하고 지금까지있을 수있는 모든 원자적이고 편안한 전화를 활용하십시오.

따라서 요청을 캐시하는 기능으로 REST의 이점을 계속 누릴 수 있습니다.

그러나 결국에는 서비스 / 서버 인프라 성능 및 클라이언트 환경을 소비해야합니다.