Genovervej grænsefladen
For det første er et brugergrænsefladedesign, der viser 50-100.000 rækker på en klient, sandsynligvis ikke den bedste brugergrænseflade i første omgang. Det er ikke kun, at en stor mængde data skal sendes ned til klienten og for klienten at administrere, og det er måske upraktisk i nogle mobile enheder, men det er åbenbart langt flere rækker, end nogen enkelt bruger rent faktisk kommer til at læse i en given interaktion med siden. Så den første ordre kan være at genoverveje brugergrænsefladedesignet og skabe en slags mere efterspørgselsdrevet grænseflade (paged, virtuel scroll, tastet med bogstav osv...). Der er masser af forskellige muligheder for et anderledes (og forhåbentlig bedre) brugergrænsefladedesign, der mindsker dataoverførslen. Hvilket design der ville være bedst afhænger helt af dataene og brugerens sandsynlige brugsmodeller.
Send data i stykker
Når det er sagt, hvis du skulle overføre så mange data til klienten, vil du sandsynligvis gerne sende det i bidder (grupper af rækker ad gangen). Ideen med chunks er, at du sender en forbrugsbar mængde data i én chunk, så klienten kan parse det, behandle det, vise resultaterne og derefter være klar til den næste chunk. Klienten kan forblive aktiv hele tiden, da den har tilgængelige cyklusser mellem bidder til at behandle andre brugerhændelser. Men at sende det i bidder reducerer omkostningerne ved at sende en separat besked for hver enkelt række. Hvis din server bruger komprimering, giver chunks også en større chance for komprimeringseffektivitet. Hvor stor en del skal være (f.eks. hvor mange rækker data skal indeholde) afhænger af en masse faktorer og bestemmes sandsynligvis bedst gennem eksperimenter med sandsynlige klienter eller den forventede klient med lavest effekt. For eksempel vil du måske sende 100 rækker pr. besked.
Brug et effektivt overførselsformat til dataene
Og hvis du bruger socket.io til at overføre store mængder data, vil du måske gense, hvordan du bruger JSON-formatet. For eksempel er det ikke særlig effektivt at sende 100.000 objekter, der alle gentager nøjagtigt de samme egenskabsnavne. Du kan ofte opfinde dine egne optimeringer, der undgår at gentage egenskabsnavne, der er nøjagtigt ens i hvert objekt. For eksempel i stedet for at sende 100.000 af disse:
{"firstname": "John", "lastname": "Bundy", "state": "Az", "country": "US"}
hvis hvert enkelt objekt har nøjagtig de samme egenskaber, så kan du enten kode egenskabsnavnene ind i din egen kode eller sende egenskabsnavnene én gang og så bare sende en kommasepareret liste over værdier i et array, som den modtagende kode kan sætte ind i et objekt med de relevante egenskabsnavne:
["John", "Bundy", "Az", "US"]
Datastørrelsen kan nogle gange reduceres med 2-3x ved blot at fjerne overflødige oplysninger.