obter todos os dados vs obter dados parciais Otimização

5

Digamos que um client faça uma chamada de GET para o server para obter todos os followers de algum usuário. agora o cliente mostra uma lista de todos os seguidores, mas os únicos dados que a lista precisa são:

{"username" : "user", "thumbUrl" : "http:/www.example.com/photo/1", "age" : 78}

agora o usuário pode clicar em um dos seguidores e ele pode ver mais dados sobre o seguidor que ele clicou.

Minha pergunta : devo trazer antecipadamente todos os dados de seguidores do servidor (total User Object) vs trazer apenas dados parciais e, em seguida, fazer outra chamada onDemand quando o usuário clicar em um seguidor . E o mais importante é se eu realmente preciso me preocupar com essas otimizações?

suposições:

  1. os dados são limitados (10 objetos por chamada para seguidores)
  2. o tamanho de cada objeto de usuário é de cerca de 1kb, parcial de cerca de 200 bytes
  3. O usuário geralmente clica em 5 seguidores para cada 10 Objetos.

Pontos de interesse:

  1. tamanho salvo : cerca de 10kb - 2kb - 5kb = 3kb por lote de 10 usuários. é insignificante nesta idade da internet? importaria se a diferença de tamanho fosse 30kb?
  2. tamanho do depósito : dei exemplos com um tamanho de depósito baixo, mas o tamanho do meu depósito pode aumentar para 2Mb . Importa se o tamanho do meu depósito for 2Mb com os dados completos do usuário vs 400kb com chamada parcial? É mais lento? (Assumindo que o usuário clicará em seguidores suficientes para fazer com que a diferença de tamanho seja insignificante
  3. Receberá quaisquer outros pontos de interesse
por royB 02.01.2015 / 19:33
fonte

2 respostas

5

Depende.

Basicamente, você precisa ver qual é a latência esperada da conexão, qual é a largura de banda e qual a capacidade de resposta desejada.

Como exemplo: suponha que a latência de ida e volta do cliente para o servidor seja de 100 ms e a largura de banda seja de 8 mb / s. Se você enviar os dados "completos" for 2Mb e os dados "parciais" forem 400kb, serão necessários 350 ms para enviar o registro "completo" e 150 msecs para enviar um registro "parcial". Se você enviar registros parciais, cada clique precisará de 110 ms para recuperar os resultados. Caso contrário, cada clique é instantâneo. Então:

  • Completo - Primeiro carregamento: 350 ms, clique em: instant
  • Parcial - Primeiro carregamento: 150 ms, clique em: 110 ms

O ponto chave é entender que cada chamada adiciona sobrecarga. Embora seja muito tentador minimizar os dados transferidos, isso pode realmente tornar as coisas mais lentas, se causar mais viagens de ida e volta.

É claro que isso é enganoso, porque chamadas de rede são variáveis. Mas pessoalmente com esses números eu ficaria tentado a carregar na frente.

Mas esta é apenas uma análise de alto nível. Outras coisas a considerar:

  • Isso ignora completamente o custo do lado do servidor. Com que rapidez os dados "completos" são comparados com os "parciais"? Você pode puxar os dados "completos", armazená-los em cache para o futuro e retornar os dados parciais?
  • O código que obtém os dados em um bloco provavelmente será mais simples no cliente e no servidor e, portanto, com menos bugs.
  • Se você enviar dados parciais, precisará se preocupar com o que acontece se os registros forem alterados entre o primeiro pull e o segundo.
  • Para os usuários, uma única chamada lenta seguida por uma capacidade de resposta instantânea é "mais rápida" do que se cada clique levar um tempo perceptível. Você quer prestar atenção em quão rápido os usuários acham que o sistema é o máximo possível com as caras medidas concretas de quão rápido o sistema realmente é.

Em geral, é melhor minimizar o número de chamadas de rede em vez de minimizar a quantidade de dados transferidos em geral. Mas isso não pode ser uma regra difícil e rápida porque, de fato, depende muito da largura de banda esperada e da latência esperada. Devo observar, porém, que a largura de banda está melhorando constantemente, enquanto a latência não deve melhorar significativamente com o tempo.

    
por 02.01.2015 / 21:08
fonte
1

Você pode definir os recursos e representações da maneira adequada às suas necessidades. Eu costumo usar GET para fornecer uma visão "resumida" de uma coleção (como "... / followers") como um recurso que fornece uma lista de resumos dos seguidores, incluindo seus ids (ou URIs se eu estiver sendo bom) . Isso geralmente é suficiente para o cliente fornecer uma lista que o usuário possa procurar e, em seguida, detalhar.

No entanto, às vezes o cliente realmente quer uma lista das coisas completas. Depende apenas do seu uso. E você sempre pode fornecer um parâmetro de string de consulta (por exemplo, "? Full = true") para alternar (embora um cabeçalho de aceitação e uma negociação de conteúdo possam ser uma maneira mais "correta", mas complicada de fazê-lo). / p>

(Quanto ao aspecto de desempenho e otimização, é difícil definir um critério específico, porque isso será baseado em muitas coisas, como seu hardware, onde ele é implantado, middleware na frente de seu serviço, etc.). obviamente) enviar menos bytes será mais rápido ... além disso, você pode fazer alguns testes de desempenho para ver quais são os limites aceitáveis.)

    
por 02.01.2015 / 21:04
fonte