Heroverweeg de interface
Ten eerste is een gebruikersinterfaceontwerp dat 50-100k rijen op een client toont waarschijnlijk niet de beste gebruikersinterface. Dat is niet alleen een grote hoeveelheid gegevens die naar de client moet worden verzonden en voor de client moet worden beheerd, en het is misschien onpraktisch op sommige mobiele apparaten, maar het zijn duidelijk veel meer rijen dan een enkele gebruiker daadwerkelijk zal lezen in een bepaalde interactie met de pagina. Dus de eerste opdracht zou kunnen zijn om het ontwerp van de gebruikersinterface te heroverwegen en een soort meer vraaggestuurde interface te creëren (gepagineerd, virtueel scrollen, gecodeerd per letter, enz...). Er zijn veel verschillende mogelijkheden voor een ander (en hopelijk beter) gebruikersinterfaceontwerp dat de hoeveelheid gegevensoverdracht vermindert. Welk ontwerp het beste is, hangt volledig af van de gegevens en de waarschijnlijke gebruiksmodellen door de gebruiker.
Gegevens in brokken verzenden
Dat gezegd hebbende, als je zoveel gegevens naar de client zou sturen, dan wil je het waarschijnlijk in brokken verzenden (groepen rijen tegelijk). Het idee van chunks is dat je een verbruikbare hoeveelheid data in één chunk stuurt, zodat de client het kan ontleden, verwerken, de resultaten kan tonen en dan klaar is voor het volgende chunk. De client kan de hele tijd actief blijven omdat er cycli beschikbaar zijn tussen chunks om andere gebruikersgebeurtenissen te verwerken. Maar als u het in brokken verzendt, vermindert u de overhead van het verzenden van een afzonderlijk bericht voor elke afzonderlijke rij. Als uw server compressie gebruikt, geven chunks ook een grotere kans op compressie-efficiëntie. Hoe groot een stuk moet zijn (bijvoorbeeld hoeveel rijen gegevens het moet bevatten) hangt af van een aantal factoren en kan waarschijnlijk het beste worden bepaald door te experimenteren met waarschijnlijke clients of de client met het laagste vermogen. U wilt bijvoorbeeld 100 rijen per bericht verzenden.
Gebruik een efficiënt overdrachtsformaat voor de gegevens
En als je socket.io gebruikt om grote hoeveelheden gegevens over te zetten, wil je misschien nog eens kijken hoe je het JSON-formaat gebruikt. Het verzenden van 100.000 objecten die allemaal exact dezelfde eigenschapsnamen herhalen, is bijvoorbeeld niet erg efficiënt. U kunt vaak uw eigen optimalisaties bedenken die herhaling van eigenschapnamen die in elk object exact hetzelfde zijn, voorkomen. Bijvoorbeeld, in plaats van 100.000 van deze te verzenden:
{"firstname": "John", "lastname": "Bundy", "state": "Az", "country": "US"}
als elk afzonderlijk object exact dezelfde eigenschappen heeft, kunt u de eigenschapsnamen in uw eigen code coderen of de eigenschapsnamen één keer verzenden en vervolgens een door komma's gescheiden lijst met waarden in een array verzenden die de ontvangende code in een object kan plaatsen met de juiste eigenschapsnamen:
["John", "Bundy", "Az", "US"]
De gegevensomvang kan soms met 2-3x worden verkleind door simpelweg overbodige informatie te verwijderen.