Felsöka prestandaproblem i ER-konfigurationer
I den här artikeln beskrivs hur du hittar och löser prestandaproblem i ER-konfigurationer (ER).
Vanligtvis består prestandaundersökningen av flera steg.
- Samla in data.
- Analysera insamlade data.
- Baserat på resultaten av analysen använder du ER-konfigurationer för att göra ändringar eller bestämmer dig för att samla in mer data.
Felsökning
Analysera körningstid
Körningstiden kan bero på oförutsägbara faktorer, till exempel andra aktiviteter som körs i samma miljö och cachelagring som använder data när de anropas för första gången. Därför bör du upprepa körningen och mätningen flera gånger.
Ibland orsakas prestandaproblem inte av en ER-formatkonfiguration som används för rapportering. Istället orsakas de av X++ -koden som används för att öppna ER-formatkonfigurationen.
I antingen Åtgärdscentret eller händelseloggen tittar du på rapportens körningstid.
Jämför körningstiden för rapporten med den totala körningstiden i scenariot.
Om körningstiden för rapporten är mycket kortare än den totala körningstiden bör du tänka på hur mycket data rapporten bearbetar:
- Om rapporten bearbetar en liten mängd data kan problemet inbegripa inläsningstiden för konfigurationen.
- Om rapporten bearbetar en stor mängd data kan problemet inbegripa förbearbetning av X++. Använd Trace parser för att analysera det här fallet.
I andra fall, se nästa avsnitt.
Kör flera tester som involverar olika mängder data för att avgöra hur körningstiden beror på mängden data.
Analysera Trace parser-spår
Förbered ett mindre exempel eller samla in flera spår under slumpmässiga delar av rapportgenereringen.
I Trace parser gör du sedan en standardanalys nedifrån och upp och besvarar följande frågor:
- Vilka är de bästa metoderna när det gäller tidsförbrukning?
- Vilken del av den totala tiden använder dessa metoder?
Besvara samma frågor för frågor.
Om du ser att metoderna föregås av "ER" går du vidare till nästa avsnitt.
Om du ser att metoder eller frågor har sitt ursprung i programsviten bör du överväga allmänna optimeringar (till exempel skapa index).
Analysera antalet anrop. Om antalet är betydligt högre än förväntat bör du överväga att cachelagra motsvarande noder i konfigurationen.
Analysera databasanrop
Förbered ett exempel som har en liten mängd data, så att du kan samla in en ER-spårning.
Öppna sedan spårningen i ER-modellmappningsdesignern och titta längst ned på sidan. Besvara följande frågor:
Finns det några frågedubbletter? Om så är fallet, överväg någon av följande korrigeringar:
- Använd cachelagring om du tror att det finns flera anrop i en enda överordnad post.
- Använd ett cachelagrat, parametriserat beräknat fält om du tror att det finns anrop till samma post i olika poster.
- Använd en KOPPLA-datakälla om du måste läsa till ett stort antal olika poster från en databas.
Motsvarar antalet frågor och hämtade poster den totala mängden data? Om ett dokument till exempel har 10 rader, visar då statistiken att rapporten extraherar 10 rader eller 1 000 rader? Om du har ett stort antal hämtade poster bör du överväga någon av följande korrigeringar:
- Använd funktionen FILTER istället för funktionen WHERE funktionen för att bearbeta data på sidan Microsoft SQL Server.
- Använd cachelagring för att undvika att hämta samma data.
- Använd insamlade datafunktioner för att undvika att hämta samma data för summering.
Analysera PerfView-spår
PerfView är ett verktyg för erfarna utvecklare. Mer detaljerad information om följande steg finns i Utredningsgrunder för processtid.
Samla in en spårning med hjälp av trådtid.
Inkludera endast staplar som använder runUnattended för att endast filtrera tråden som har konfigurationskörning. (Lägg till runUnattended i indatarutan IncPats.)
Vik all processor-, nätverks- och blockerad tid.
Läs in ER-förinställningar för PerfView.
Välj ER>Annan förinställning.
Titta på namnen:
Du kommer förmodligen att se den plattformskod som förbrukar mest tid.
Du kan dubbeltrycka (eller dubbelklicka) och gå upp via mottagare.
Om du hittar klasser som har prefixet "ERExpression", och om dessa är funktioner som är relaterade till formler kan du gissa funktionsnamnet baserat på klassnamnet och du kan titta på ER-lagringsplatsen för att visa attributen.
Korrigeringar
Om du ser att större delen av processortiden förbrukas av frågor försöker du minska antalet frågor:
- Granska ER-spårningen för duplicerade frågor.
- Se hur många poster som hämtas och utvärdera hur mycket data som teoretiskt ska hämtas.
Om du ser att större delen av processortiden förbrukas av de funktioner som används kan du försöka hitta den plats i konfigurationen som förbrukar flest resurser.
Om du ser att större delen av processortiden förbrukas av datainsamlingsfunktioner bör du överväga att ersätta dem med SQL-grupp efter på modellmappningssidan.
Datainsamling
Beroende på din miljö finns det flera sätt att samla in tillgängliga data:
Få den totala körningstiden:
- Från åtgärdscentret
- Från händelseloggen
Profilera körningen:
- Genom att använda ER-verktyg
- Genom att använda Trace parser
- Genom att använda PerfView
Samla in data i en produktionsmiljö
Ibland kan problem endast reproduceras i en produktionsmiljö. Data kan samlas in på följande sätt:
- Genom att använda Trace parserspår.
- Genom att använda spårningar efter ER-körning
- Genom att använda den totala körningstiden
Samla in data i en utvecklingsmiljö
Förutom de verktyg som kan användas i en produktionsmiljö finns det flera verktyg du kan använda i en utvecklingsmiljö:
- Händelselogg (Microsoft-Dynamics-ElectronicReporting). Denna logg kan ge dig den totala körningstiden.
- Vanliga .NET-verktyg, till exempel PerfView.
Dessutom ger en utvecklingsmiljö dig mer flexibilitet att experimentera. Du kan till exempel stänga av delar av rapporter för att se hur körningstiden påverkas.
Verktyg
Körningstid i åtgärdscentret
ER kan visa körningstiden för konfigurationen i åtgärdscentret. Detta alternativ fungerar bara för en viss användare och ett visst företag, och endast för interaktiva sessioner. Följ dessa steg för att göra denna funktion tillgänglig.
- Gå till Organisationsadministration>Elektronisk rapportering>Konfigurationer.
- På sidan Konfigurationer i åtgärdsfönstret, på fliken Konfigurationer i gruppen Avancerad inställningar markerar du Använd parametrar.
- I dialogrutan Användarparametrar anger du alternativet Visa genereringstid för fil som Ja.
Körningstid i händelseloggen
- Öppna Loggboken i Windows.
- Under Program- och tjänsteloggar öppnar du Microsoft-Dynamics-ElectronicReporting/Operational.
- Leta efter FormatMapingRun-händelser där EventID=2, detta eftersom dessa händelser innehåller information om förfluten tid.
Trace parser-spår
Eftersom ER implementeras i X++kan du använda vanliga X++ -verktyg för att analysera prestanda. Mer information finns i Spåra med hjälp av Trace parser.
Det finns några begränsningar i samband med detta tillvägagångssätt. Eftersom en del av ER implementeras i C# kommer inte alla detaljer att vara tillgängliga. Du kan dock visa detaljerad information om dataanvändningen. Dessutom kan långa rapportkörningar komma att överskrida begränsningar för spårningslagring.
ER-spår
ER kan samla sina egna spår, och har visualiserings- och analysverktyg för dessa spår. För mer information, se Spåra körningen av ER-format för att felsöka prestandaproblem.
PerfView
Eftersom både X++ och ER implementeras ovanpå .NET-plattformen kan du använda vanliga .NET-verktyg. Du kan till exempel använda det kostnadsfria verktyget PerfView.
Du kan också samla in data från kommandoraden. Följande Windows PowerShell-skript samlar till exempel in körningstiden tills alla formatkörningar stoppats på datorn.
c:\programs\PerfView collect "e:\traces\$(date -format "ddMMyyyy_hhmm").etl" `
-CircularMB:20000 -ThreadTime `
-NoNGenRundown `
-StopOnEtwEvent:Microsoft-Dynamics-ElectronicReporting/FormatMappingRun/Stop
Det finns några begränsningar i samband med detta tillvägagångssätt. Du måste ha administratörsåtkomst till maskinen. Du måste dessutom vara en erfaren utvecklare, detta eftersom inlärningskurvan är brant.
Göra ändringar
Använd cachelagring
Även om cachelagring minskar den tid som krävs för att hämta data igen, så kostar den minne. Använd cachelagring i de fall där mängden hämtade data inte är särskilt stor. Mer information och ett exempel som visar hur du använder cachelagring finns i Förbättra modellmappningen baserat på information från körningsspårningen.
Minska volymen av data som hämtas
Du kan minska minnesförbrukningen för cachning genom att begränsa antalet fält i posterna i ett programregister som du hämtar vid körning. I det här fallet hämtar du bara de fältvärden för ett programregister som du behöver i ER-modellmappningen. Andra fält i den tabellen hämtas inte. Därför minskas den volym av minne som krävs för cachehämtning av poster. Mer information finns i Förbättra prestandan för ER-lösningar genom att minska antalet registerfält som hämtas under körning.
Använd ett cachelagrat, parameteriserat beräknat fält
Ibland måste värdena sökas upprepade gånger. Exempel på detta är kontonamn och kontonummer. För att spara tid kan du skapa ett beräknat fält som har parametrar på den översta nivån och sedan lägga till fältet i cacheminnet.
Vi rekommenderar att du bara använder den här metoden när storleken på cachelagrade data är liten. Mer information finns i Förbättra prestanda för ER-lösningar genom att lägga till parametriserade datakällor för BERÄKNADE FÄLT.
Använd en KOPPLA-datakälla
Med en KOPPLA-datakälla kan flera anslutna poster hämtas av en enda fråga. En separat fråga behöver inte användas för att hämta varje ansluten post. Om du till exempel har 1 000 rader och hämtar artikeldata för respektive rad efter relation, får du 1 001 frågor (= 1 000 + 1). Om du använder en KOPPLA-datakälla använder du bara en enda fråga för att hämta samma data. Se Använd KOPPL-datakällor i ER-modellmappningar för att hämta data från flera programtabeller om du vill ha mer information.
Använd funktionen FILTER istället för funktionen VAR
Funktionen FILTER kör villkor på SQL Server, medan funktionen VAR hämtar alla data i listan - en post i taget - och applicerar villkoret för respektive post. Du vill till exempel välja en enda post av 1 000 poster. Om du använder VAR hämtas alla 1 000 poster. Om du emellertid använder FILTER hämtas exakt en (1) post. FILTER kan också använda index på databassidan.
Använda insamlade datafunktioner eller en ackumulerad datakälla
Om konfigurationen har en gruppera efter-komponent som sammanfattar tidigare hämtade data efter rapport, hämtar komponenten alla data igen. Genom att använda insamlade datafunktioner gör du det möjligt för ER att samla in data under den första hämtningen. Mer information finns i Konfigurera format för inventering och summering i ER.
Skriva om delar av konfigurationen i X++
ER stöder anropmetoder för tabeller och klasser, inklusive tillägg. Överväg att skriva om delar av modellmappningen i X++ för att förbättra prestandan.
ER kan använda data från följande källor:
- Klasser (datakällorna objekt och klass)
- Tabeller (datakällorna tabell och tabellposter)
ER programprogrammeringsgränssnitt (API) ger också ett sätt att skicka förberäknade data från den anropande koden. Programserien innehåller många exempel på den här metoden.