Bij een Ax 2009 gebruiker waren al diverse reputabele partijen geweest vanwege performance problemen die al diverse punten hebben aangehaald. Voornamelijk netwerk topologie punten. Maar alsnog geen soelaas.
Situatie schets; de servers worden gehost in een datacenter. Gebruikers hebben een thin client die een remote desktop verbinding maken met een terminal server (TS) in dit datacenter. In dit datacenter staat de Ax AOS met op diezelfde server de database. Zelf als externe Ax consultant had ik via RDP toegang tot de servers. Aangezien de TS nog wat extra software had voor de eindgebruikers het melden even waard. De TS zelf is Windows 2012 R2, de server zelf is Windows 2008.
Eigenlijk kwam het terug tot dit; een standaard tabel, de InventJournalTrans op een schoon formulier met enkel een tab en een grid als admin ging de performance dramatisch onderuit als alle velden op de grid werden opgenomen. Als je het opende:
Her duurde tot wel 30 seconden voordat het scherm verder werd opgebouwd. En dan nog; het scherm werd zichtbaar opgebouwd:
Het klikken tussen de records zat merkbaar een vertraging in: duurde soms enkele seconden voordat een regel gearceerd werd. Eigenschappen van het form:
- Kaal formulier met één tab, één grid, > 40 velden
- Geen edit/display methoden enkel velden dit in de tabel zitten.
- Openen vanuit AOT, geen rechten, geen methoden geïmplementeerd(init, run, active, executeQuery, linkactive), eigen queries, sortering or andere properies van de componenten.Zelfs niet eens de moeite genomen de tab een label te geven.
Via de tabel-browser van Ax was de tabel met al zijn velden wel snel benaderbaar.
Bij minder velden (< 20) ging het goed en snel. De situatie is echter, dat na minimaliseren en restoren van het form de performance ineens goed was bij meer dan 20 velden. Deze code opgenomen onder een knop:
WinAPI::showWindow(element.hWnd(), 6); // 6 = minimize
WinAPI::showWindow(element.hWnd(), 9); // 9 = restore
Het scherm knippert even, maar de performance is uitstekend. Het opstarten van het formulier is echter nog steeds traag.
Het feit dat de schermen snel zijn na een minimize/restore geeft mij aan dat het probleem niet in Ax of in de netwerk verbinding zit. Maar waarom is de tabel-browser dan wel snel? Deze velden worden dynamics toegevoegd...Uiteindelijk kwam ik er achter dat verborgen velden hetzelfde effect had:
In de run:
De refreshForm:
Het direct zichtbaar maken in de run (de na de super in de run meteen refreshForm aanroepen) maakte het systeem al wel wat sneller, maar het selecteren van andere records bleef traag.
Een aantal dingen die ik geprobeerd heb:
- Kernel AOS/client bijwerken (laatste versie op dit moment: 5.0.1600.3696)
- Al het maatwerk in de basis zoals SysSetupFormRun, Info, Application etc. die eventueel problemen zou kunnen veroorzaken verwijderen (echt de laag zelf verwijderen).
- Diverse calls zoals yield(), winapi calls die ik kon vinden die mogelijk messages voor een form afhandelde / opschoonde.
- Applicatie zaken (verwijderen UAC, verwijderen *.I, met herstart AOS uiteraard)
Andere bevindingen;
- Vanaf de TS was het sneller dan rechtstreeks op de server. Dit kan verklaard worden doordat resources op de server beperkter zijn (SQL server wil nogal geheugen claimen). Het scherm opende wel sneller, maar het selecteren van andere records bleef traag tot het scherm geminimaliseerd / gerestored is.
- Het maakt niet uit voor de server: Windows 2012 R2 met client applicaties en de Ax client die verbinding maakt met een Windows 2008 AOS+DB heeft dezelfde eigenschap als alles op één Windows 2008 machine (client en AOS en DB)
- Aangezien het minimaliseren / restoren van het Form al het euvel verhelpt en de kaalheid van het form, is het mijn insteek dat het niet in de applicatie van Ax zit maar mogelijk in de Ax client zelf icm windows al-dan-niet icm een derde applicatie.
Uiteindelijk heb ik deze functionaliteit meegenomen in de applicatie;
Dus alleen velden dit zicthbaar zijn aan het eind van de init -> verbergen
Dus alles dat inzichtbaar is gemaakt, weer zichtbaar maken. Een minimize/restore kan ook, zie uitgecommentarieerde code. Maar dat flikkert wel het scherm dus.
De timeout in de run:
Dit is geen oplossing voor het probleem, maar meer een workaround voor de symptomen. Tot zover... mocht iemand zoeken naar performance problemen, kan je hier misschien wat mee. Als iemand anders nog ideeën of tips heeft, dan hoor ik dat ook graag.
