Performance over wan upspeeden

[Roger]

Het valt me altijd op dat de snelheid van een FM applicatie zo ontzettend naar beneden gaat wanneer de applicatie draait op een externe server buiten het lan. Vooral met loops en veldinhoud vervangen bij grotere hoeveelheden records. Venster vastzetten, weet ik, is een goeie om de snelheid erin te houden als er naar gerelateerde records wordt geswitcht. Zijn er nog meer tips en tricks op dit punt? 

[Peter Wagemans]

• houdt je gevonden sets klein
• sorteer alleen als je absoluut moet
• optimaliseer je layouts zodat er zo weinig mogelijk aangepaste stijlen zijn
• optimaliseer je layouts door SVG graphics te gebruiken ipv andere beeldformaten, en als je die toch moet gebruiken, check de resolutie
• zorg dat je bestand geen gevulde globals heeft, voor je het begint te hosten
• probeer zware data operaties door te geven aan een server side script
• probeer velden die veel data bevatten, op te splitsen in een gerelateerde tabel
• weeg af of je data moet stockeren in calculaties, of dat je deze calculaties "unstored" moet maken
• soms is het sneller om NIET naar gerelateerde records te switchen, en via een ouwerwetse zoekopdracht te gaan.
• vermijdt de "flush cache" script stap

Om maar een paar truukjes te vernoemen.

[Roger]

Dank je voor je antwoord Peter. Best wat punten waar ik nooit rekening mee houd en dus goed om te weten! 

Ik ontdek er zelf net ook nog eentje. Door juist wel de scriptstap 'Ga naar gerelateerd record' toe te voegen en aldaar mijn loop uit te voeren (die maximaal 90 keer een kleine test doet) boek ik een factor 3 snelheidsverbetering. (Wachttijd loopt terug van 9 naar 3 sec.) Ik vraag me af wat hiervan de belangrijkste oorzaak is, het feit dat de loop nu vanuit een statische layout plaatsvindt i.p.v. een dynamische, of dat er nu een TOC minder tussen zit? Ik vermoed zelf het eerste. Op de layout van mijn vertrekpunt staan namelijk wat portals met velden met een voorwaardelijke (van mijn loop afhankelijke) opmaak. Dit geeft dan wel te denken over het nut van 'Venster vastzetten', want je zou denken dat er op de layout niks hoeft te veranderen tot het script is afgerond of tot het venster vernieuwd wordt.

Omdat ik het allemaal erg graag wil begrijpen heb ik ter test nog geprobeerd in mijn script de 'gewraakte objecten' tijdens de loop te verbergen. Dit levert echter geen snelheidswinst op.

[Banach]

Of andere test: vanaf een layout waar de objecten welke niet nodig zijn niet op aanwezig zijn.

[hans erik]

On 2/19/2020 at 1:03 PM, Peter Wagemans said:

• houdt je gevonden sets klein
• sorteer alleen als je absoluut moet
• optimaliseer je layouts zodat er zo weinig mogelijk aangepaste stijlen zijn
• optimaliseer je layouts door SVG graphics te gebruiken ipv andere beeldformaten, en als je die toch moet gebruiken, check de resolutie
• zorg dat je bestand geen gevulde globals heeft, voor je het begint te hosten
• probeer zware data operaties door te geven aan een server side script
• probeer velden die veel data bevatten, op te splitsen in een gerelateerde tabel
• weeg af of je data moet stockeren in calculaties, of dat je deze calculaties "unstored" moet maken
• soms is het sneller om NIET naar gerelateerde records te switchen, en via een ouwerwetse zoekopdracht te gaan.
• vermijdt de "flush cache" script stap

Om maar een paar truukjes te vernoemen.

Wat betreft je opmerking over graphics en stijlen: als een graphic onderdeel maakt van een theme (een button icon bijv.) wordt die toch maar 1x naar de client gedownload? Zodra je buiten de stylesheet om graphics gaat toepassen schijnt de dataload aanzienlijk groter te worden.

[Peter Wagemans]

13 uur geleden zei hans erik:

Wat betreft je opmerking over graphics en stijlen: als een graphic onderdeel maakt van een theme (een button icon bijv.) wordt die toch maar 1x naar de client gedownload? Zodra je buiten de stylesheet om graphics gaat toepassen schijnt de dataload aanzienlijk groter te worden.

Dat bedoelde ik ook, maar deze vlaming verwoorde het niet zo goed.