sql >> Databasteknik >  >> RDS >> Mysql

socket.io prestanda en emit per databasrad

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.




  1. oratop

  2. Hur spolar man performance_schema-statistik utan att starta om MySQL?

  3. Android Room - Hantera lista över objekt i ett objekt och frågeresultat

  4. Generera CREATE-satser för alla MySql-tabeller