Archief - Snelheidsinvloed van lengte index namen in JSON object

Hey iedereen

Situatie: Ik heb een pagina waarmee een school oudercontacten kan regelen: ze zien voor een leerkracht alle leerlingen die op oudercontact willen komen en per leerling alle momenten beschikbaar voor dat oudercontact (met kleurcodes wordt aangeduid welke momenten nog beschikbaar zijn, welke reeds vastgelegd).

Elk moment voor elke leerling is aanklikbaar, via ajax wordt de keuze bewaard en wordt er een json array teruggegeven met wie waar is aangevinkt (vaak werkt men met meerdere mensen tegelijk, ik moet dus steeds ALLE data terugkrijgen om de volledige pagina te updaten). Nu, voor grote scholen loopt dit aantal aanklikbare momenten al vlug op tot een paar 100 links op de pagina (20 leerlingen voor een leerkracht en gemakkelijk 30 momenten). Dat is dus ook heel veel data die ik terugkrijg via ajax om te verwerken. En dat voel je in de performance: eenmaal de link is aangeklikt, "hapert" de pagina toch wel vlug een seconde.

Nu werken we met nogal lange veldnamen in onze databases (keuze van onze leaddev), dingen als "OuderContactPeriodeDetailID" zijn regelmaat en die veldnamen staan dus ook in de json die terugkeert.

Nu vroeg ik me af: moest ik die veldnamen afkorten in de json, zou dat invloed hebben op de snelheid?

Korte datavelden gebruiken zou enkel een invloed hebben wanneer bandbreedte een probleem is.

Bij performantieproblemen is 1 gouden regel: meten is weten. Wat loopt er fout?
Je kan best eens kijken hoe lang alles duurt:
- Het ophalen van de data op de server (trage query?)
- Het ontvangen de de data (te grote dataset?)
- Het parsen van de data en updaten van je pagina (inefficiënte JS?)

Voor deze eenvoudige case kan je gewoon enkele timestamps nemen op de verschillende momenten (vb. eentje wanneer je je request doet (op de knop klikt), eentje wanneer je je data binnenkrijgt en eentje wanneer de verwerking klaar is). Pas als je weet waar de meeste tijd in kruipt, zal je weten hoe je het best kan aanpakken.

(Cycloon geeft trouwens al een correct opmerking. Als dat het probleem is kan je je data eventueel ook gaan comprimeren, met bijvoorbeeld deflate, maar als de dataset te klein is, is de kans groot dat het uiteindelijk toch trager is door de overhead van het (de)comprimeren en zal je dus enkel verlies boeken. Experimenteren en meten is de boodschap!)

ligt nogal dikwijls aan niet-efficiente clientside code ... vooral omdat je zegt dat je browser hangt.

hier alvast een interessant artikel mbt jquery optimalisatie
24 ways: Your jQuery: Now With 67% Less Suck

edit: hoe lang het duurt eer je je json terugkrijgt van de server: in chrome duw je op f12, klik op Network, klik op xhr.. testen maar

Offtopic: mag ik weten welk systeem je dan verzorgt? Blackboard?

BramVroy zei:

Blackboard?

Klik om te vergroten...

Veel keuze is er daarin niet

GigaPixels zei:

Veel keuze is er daarin niet

Klik om te vergroten...

Off the top of my head:

• Blackboard
• Moodle
• Sakai
• Claroline
• Chamilo
• Learn eXact

Er zullen er wel nog meerdere zijn..

Ontopic:
Veel gaat korteren JSON keynames mijns inszien niet veel uitmaken. Opstellen van uurroosters is NP hard, dus het kan zijn dat je hier een algoritme hebt dat niet efficient op te lossen valt. Hoewel het lijkt dat dat niet helemaal is wat je hier probeert te doen?

't Is geen van de spelers die actief zijn binnen het hoger onderwijs, we werken uitsluitend samen met kleuter, lager en secundair onderwijs.

't Is inderdaad ook geen algoritme dat de planning zelf opstelt, deze wordt door de scholen zelf gedaan.

Ik neem aan dat je voor schoolonline.be werkt?

Anyway, als je toch elke keer een volledig dataset moet ophalen kan je best gewoon een loader weergeven, die 1-2s zijn nog aanvaardbaar.

M'n ex-werkgever heeft een projectmanagement-systeem in ASP.NET, sommige van die onderdelen duren 15s en meer om te laden. Belachelijk lang maar klanten kunnen er blijkbaar mee leven, ik alvast niet