ottenere tutti i dati e ottenere l'ottimizzazione parziale dei dati

Question

ottenere tutti i dati e ottenere l'ottimizzazione parziale dei dati

#1 da (5 voti)
#2 da (1 voti)

5

Diciamo che client effettua una chiamata GET alla server per ottenere tutto il followers di un utente. ora il client mostra un elenco di tutti i follower ma gli unici dati di cui ha bisogno l'elenco sono:

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

ora l'utente può fare clic su uno dei follower e può visualizzare più dati sul follower su cui ha fatto clic.

La mia domanda : dovrei portare tutti i dati dei follower dal server (full User Object) vs portare solo dati parziali e poi fare un'altra chiamata onDemand quando usclicks un follower . E più importante è se devo davvero preoccuparmi di tali ottimizzazioni?

ipotesi:

i dati vengono limitati (10 oggetti per chiamata ai follower)
di ciascun oggetto utente è di circa 1kb, parziale di circa 200 byte
L'utente di solito fa clic su 5 follower per ogni 10 oggetti.

Punti di interesse:

dimensioni salvate : circa 10kb - 2kb - 5kb = 3kb per bucket di 10 utenti. è trascurabile a questa età di Internet? sarebbe importante se la differenza di dimensione fosse 30kb?
dimensione del bucket : ho fornito esempi con dimensioni del bucket ridotte, ma la dimensione del mio bucket può arrivare fino a 2Mb . Ha importanza se la dimensione del mio bucket è 2Mb con i dati completi dell'utente rispetto a 400kb con chiamata parziale? È più lento? (Supponendo che l'utente farà clic su un numero sufficiente di follower per rendere trascurabile la differenza di dimensione
Accoglierà qualsiasi altro punto di interesse

http-request rest optimization client-server

posta royB 02.01.2015 - 19:33

fonte

2 risposte

1

È possibile definire le risorse e le rappresentazioni nel modo più adatto alle proprie esigenze. Di solito uso GET per fornire una vista "riassuntiva" di una raccolta (come "... / followers") come una risorsa che fornisce un elenco di riepiloghi dei follower, inclusi i loro id (o URI se sono bravo) . Solitamente è sufficiente che il client fornisca un elenco che l'utente può esplorare e quindi eseguire il drill-down in.

Tuttavia, a volte il cliente vuole davvero una lista delle cose complete. Dipende solo dal tuo utilizzo. E puoi sempre fornire un parametro stringa di query (ad esempio "? Full = true") per passare avanti e indietro (anche se un'intestazione di accettazione e la negoziazione del contenuto potrebbero essere un modo "corretto" ma complicato per farlo).

(Per quanto riguarda l'aspetto delle prestazioni e dell'ottimizzazione, è difficile definire un criterio specifico, poiché si baserà su molte cose come l'hardware, dove è distribuito, il middleware di fronte al tuo servizio, ecc. ovviamente) l'invio di un numero inferiore di byte sarà più veloce ... oltre a ciò, è possibile eseguire alcuni test delle prestazioni per vedere quali sono le soglie accettabili.)

risposta data 02.01.2015 - 21:04

fonte

Leggi altre domande sui tag http-request rest optimization client-server

Qual è un ragionevole livello di dettaglio per una guida di stile? [chiuso] Devo convalidare l'output dell'API?

score 5 · Accepted Answer

Dipende.

Fondamentalmente, devi considerare quale sia la latenza prevista della connessione, quale sia la larghezza di banda e quale sia la risposta che desideri.

Ad esempio: supponiamo che la latenza del round trip da client a server sia 100 msecs e che la larghezza di banda sia di 8 mb / s. Se invii i dati "completi" è 2Mb e i dati "parziali" sono 400kb, allora ci vorranno 350 msec per inviare il record "pieno" e 150 msec per inviare un record "parziale". Se si inviano record parziali, ogni clic richiede 110 msec per recuperare i risultati. Altrimenti, ogni clic è istantaneo. Quindi:

Completo: primo caricamento: 350 msec, fare clic su: instant
Parziale - Primo caricamento: 150 msec, clic: 110 msec

Il punto chiave è capire che ogni chiamata aggiunge un sovraccarico. Mentre è molto allettante ridurre al minimo i dati trasferiti, questo può effettivamente rallentare le cose, se provoca più round trip.

Naturalmente, questo è di per sé fuorviante perché le chiamate di rete sono variabili. Ma personalmente con questi numeri sarei tentato di caricare in anticipo.

Ma questa è solo un'analisi ad alto livello. Altre cose da considerare:

Questo ignora completamente il costo lato server. Quanto sono veloci i dati "completi" rispetto a quelli "parziali"? Puoi estrarre i dati "completi", memorizzarli in cache per il futuro e restituire il partial?
Il codice che ottiene i dati in un blocco è probabilmente più semplice su client e server, e quindi meno bug.
Se invii dati parziali, devi preoccuparti di cosa succede se i record cambiano tra il primo pull e il secondo.
Agli utenti, una singola chiamata lenta seguita da una risposta immediata si sente "più veloce" rispetto a quando ogni singolo clic richiede un tempo notevole. Vuoi prestare attenzione a quanto gli utenti ritengono che il sistema sia il più possibile a costo di misure concrete della velocità del sistema.

In generale, è meglio ridurre al minimo il numero di chiamate di rete anziché ridurre al minimo la quantità di dati trasferiti in generale. Ma questa non può essere una regola dura e veloce perché, di nuovo, dipende in realtà sia dalla larghezza di banda prevista che dalla latenza prevista. Devo tuttavia notare che la larghezza di banda migliora costantemente, mentre è improbabile che la latenza migliori significativamente nel tempo.