É uma boa idéia mesclar várias solicitações HTTP para economizar largura de banda?

14

Estou preparando um aplicativo de página única que às vezes seria usado em conexões móveis lentas. Algumas de suas partes são bastante pesadas em termos de solicitações de API (buscando dez recursos diferentes para uma nova exibição de tela).

Agora, é uma boa ideia mesclar esses serviços para um que forneça todos os dados necessários, mas não seja tão "puro" em termos de princípios REST? Há ganhos significativos de desempenho a serem esperados?

    
por Lukáš Lánský 05.08.2014 / 18:22
fonte

4 respostas

18

Uma das vantagens do REST é a capacidade de armazenar em cache as solicitações por meio de caches http tradicionais (supondo que sejam solicitações armazenáveis em cache).

Quando você tem solicitações únicas, maiores, usadas com menos frequência e possivelmente diferentes (vou buscar itens a,b,c,d desta vez e itens a,b,d,e da próxima vez), você torna a solicitação mais provável de ser uma falha de cache e expiram de um cache que pode estar em algum lugar entre você e a fonte.

Dado os dois conjuntos de solicitações mencionados acima, a segunda solicitação pode ter uma taxa de hit de 75% de cache e ser substancialmente mais rápida buscando apenas e , em vez de todas as quatro coisas.

Observe que isso pode não ser imediatamente aparente para as pessoas que o usam, já que a pessoa que faz o primeiro conjunto de solicitações de falta de cache ainda terá os erros de cache.

Isso não quer dizer que seria ideal em uma conexão de rede móvel em que é menos provável que ocorram hits de cache não locais. Mas para pontos de acesso ou outras situações de Wi-Fi, os acertos do cache podem ser muito mais úteis.

Grande parte disso, novamente, está sujeita a como seu aplicativo funciona. Ele está pedindo todos esses dados na inicialização? ou estamos falando de um carregamento de página em que as expectativas de tempo de resposta são diferentes?

O ideal seria testar isso para ver como sua aplicação é pré-formada em diversas situações. Considere configurar uma situação em que você tenha vinculado seu dispositivo móvel a uma rede Wi-Fi local que possa monitorar a> (esse é apenas o primeiro hit no google) e simulando uma conexão de internet ruim para ver como as coisas realmente funcionam (ou não) e qual delas tem o melhor desempenho.

    
por 05.08.2014 / 19:19
fonte
8

Sua intuição está um pouco correta - em geral, fazer menos pedidos é certamente preferível; APIs robustas tendem a ser melhores. Especialmente com conectividade instável, onde você pode ver algum trabalho e alguns não conseguem criar cenários de pesadelo, pois nada pode confiar em nada.

Há uma grande advertência: você pode ficar muito volumoso e suas chamadas e respostas ficarem inchadas. Por exemplo, pode fazer sentido ter uma grande chamada quando você acessa uma página pela primeira vez e depois as atualizações são transmitidas em pequenas mordidas, em vez de forçar uma grande atualização de página toda vez que você quiser dados.

Ou você vai querer fazer as duas coisas com toda a probabilidade.

    
por 05.08.2014 / 18:29
fonte
5

Confira este artigo do Dropbox Tech Blog .

Lá eles descrevem detalhadamente por que e como implementaram exatamente a solução que você propôs para recuperar as miniaturas de todas as suas fotos. Deve-se dizer que eles medem o desempenho para ver se vale a pena, e aparentemente é.

Breve resumo:

O site do Dropbox precisa carregar centenas de miniaturas. Devido a limitações em alguns navegadores, nem todas as miniaturas são carregadas em paralelo (as solicitações são enfileiradas). Eles queriam usar o SPDY , mas não puderam fazê-lo porque partes de seu sistema ainda não o suportam. No final, eles usaram solicitações em lote sobre HTTP, que retornam várias miniaturas por resposta em um formato compactado. A melhoria geral do tempo de carregamento da página foi de 40%, de acordo com os resultados.

    
por 06.08.2014 / 05:20
fonte
3

Resumindo: Sua abordagem é um pouco correta e pode se beneficiar de um serviço de wrapper.

Este serviço combinará as chamadas individuais existentes em um método do lado do serviço. Fazendo isso combinando chamadas do cliente para o lado do serviço & utilizando todas as chamadas únicas, atômicas e repousantes que você provavelmente já tem no lugar.

Assim, você continuaria a se beneficiar do REST como a capacidade de armazenar as solicitações em cache.

No entanto, no ponto final, tudo se resumirá ao desempenho da infraestrutura de serviço / servidor e ao ambiente do cliente que deve consumi-lo.

    
por 05.08.2014 / 19:21
fonte

Tags