Il server richiede l'ottimizzazione - dimensione vs frequenza

Per le prestazioni del server dipende in qualche misura dal collo di bottiglia della CPU o dalla larghezza di banda, ma per mancanza di dati migliori è possibile presumere che l'overhead della richiesta sia equivalente a 10 kB di dati.

Per l'utente è leggermente diverso, chiunque disponga di una connessione a velocità ragionevole vorrebbe soprattutto che la tua applicazione fosse reattiva, per questo motivo la soluzione a pacchetto grande potrebbe essere preferibile.

Un'altra cosa, se le dimensioni contano, un formato di dati XML non è probabilmente la scelta giusta.

Modifica: Personalmente di solito finisco per creare un formato dati quasi-binario personalizzato per tali cose, ma probabilmente ho la tendenza a strafare un po 'la compressione, perché è divertente.

In ogni caso, anche le cose che influiscono maggiormente sulle dimensioni dei dati sono le più semplici. JSON è una buona base, ma il classico stile JSON è piuttosto XML-ish. Il più grande overhead trovato in JSON è di solito tipi di dati a valore-chiave, in questo modo:

data={
    foo:356682,
    bar:"something",
    foobar:true
}

Con la stessa struttura ripetuta per un carico di datapoint, il passaggio da chiavi esplicite a chiavi implicite è il primo passo, invece di quello precedente si usa qualcosa del tipo:

data=[
    356682,
    "something",
    true
]

I dati devono ora essere nello stesso ordine esplicito per rendere possibile l'estrazione di dati inequivocabile, ma il vantaggio in termini di dimensioni è evidente.

Altre opzioni includono l'uso di stringhe delimitate internamente piuttosto che di matrici di stringhe, numeri di codifica di base 64 e in generale creatività riguardo alla scelta del più breve dei modi in cui è possibile rappresentare qualsiasi parte di dati.

data="BXFK|something|1"

Come per lo zippamento, non è magico, specialmente se si utilizza un algoritmo abbastanza veloce da essere eseguito in tempo reale su un server occupato. Lo sviamento normale non ottiene l'immagine più ampia, si noterà che {foo: , ,bar:" e ",foobar: sono schemi comuni e riservano identificatori relativamente brevi per questi, ma non va in giro ripetendo più volte questi identificatori. Inoltre, più rimuove un overhead, migliore sarà l'algoritmo zip che gestirà la ridondanza nei dati effettivi. Non sorprenderti se hai creato qualcosa che sembra abbastanza compatto e un semplice zip, quindi taglia le dimensioni a metà.

Il grande kicker è come si connettono i client. I server sono facili da ottenere pipe grasse e reattive e impostano il caching di fantasia / riduzione / precomputing della mappa per risolvere problemi di scala. I clienti sono molto più difficili. Se prendi di mira le aziende con grandi tubi grassi e un sacco di hardware che potrebbe spingere verso qualcosa di più loquace. Se sei preoccupato per i telefoni cellulari del terzo mondo con connessioni di 2.5 g scadenti, dovrai giocare a giochi attenti sul bilanciamento tra chattyness e dimensioni del payload. Ma tieni presente che spesso è più costoso aprire quella connessione HTTP piuttosto che trasferire il carico utile. A causa di questo, mi sbaglierei verso il lato meno chiacchierone - la larghezza di banda, il numero di connessioni no.