Tänk om gränssnittet
För det första är en användargränssnittsdesign som visar 50-100k rader på en klient förmodligen inte det bästa användargränssnittet i första hand. Det är inte bara en stor mängd data att skicka ner till klienten och för klienten att hantera och det är kanske opraktiskt i vissa mobila enheter, utan det är uppenbarligen mycket fler rader än någon enskild användare faktiskt kommer att läsa i en given interaktion med sidan. Så, den första ordern kan vara att ompröva användargränssnittets design och skapa något slags mer efterfrågestyrt gränssnitt (sökt, virtuellt rullande, knappat med bokstav, etc...). Det finns massor av olika möjligheter för en annan (och förhoppningsvis bättre) användargränssnittsdesign som minskar mängden dataöverföring. Vilken design som skulle vara bäst beror helt på data och de troliga användningsmodellerna av användaren.
Skicka data i bitar
Som sagt, om du skulle överföra så mycket data till klienten, kommer du förmodligen att vilja skicka den i bitar (grupper av rader åt gången). Tanken med chunks är att du skickar en förbrukningsbar mängd data i en chunk så att klienten kan analysera den, bearbeta den, visa resultaten och sedan vara redo för nästa chunk. Klienten kan vara aktiv hela tiden eftersom den har tillgängliga cykler mellan bitar för att bearbeta andra användarhändelser. Men att skicka det i bitar minskar kostnaden för att skicka ett separat meddelande för varje enskild rad. Om din server använder komprimering, ger chunks också en större chans för komprimeringseffektivitet. Hur stor en bit ska vara (t.ex. hur många rader med data som ska innehålla) beror på en mängd faktorer och bestäms troligen bäst genom experiment med troliga klienter eller den förväntade klienten med lägst effekt. Du kanske till exempel vill skicka 100 rader per meddelande.
Använd ett effektivt överföringsformat för data
Och om du använder socket.io för att överföra stora mängder data, kanske du vill se hur du använder JSON-formatet igen. Att skicka 100 000 objekt som alla upprepar exakt samma egenskapsnamn är till exempel inte särskilt effektivt. Du kan ofta uppfinna dina egna optimeringar som undviker att upprepa egenskapsnamn som är exakt lika i varje objekt. Till exempel, istället för att skicka 100 000 av dessa:
{"firstname": "John", "lastname": "Bundy", "state": "Az", "country": "US"}
om varje enskilt objekt har exakt samma egenskaper kan du antingen koda egenskapsnamnen till din egen kod eller skicka egenskapsnamnen en gång och sedan bara skicka en kommaseparerad lista med värden i en array som den mottagande koden kan lägga in i ett objekt med lämpliga egenskapsnamn:
["John", "Bundy", "Az", "US"]
Datastorleken kan ibland minskas med 2-3 gånger genom att helt enkelt ta bort redundant information.