none
Lagerstatus kører meget langsomt.

    Spørgsmål

  • Lagerstatus kører OK ( 2-3 minutter), hvis der logger 1 bruger ind som eneste bruger på C5 2010.

    ALLE andre kombinationer (incl at nr.2 bruger logger af, mens Nr.1 bliver inde) giver afviklingstid på ca 30 minutter.

    Server2003 som Filserver, Arbejdsstation med XP. NATIV database på ca 350 MB, ca 4.500 V-Numre

    Også testet på andet serversystem med nyinstalleret C5 Ver 4.3.1.0

    Nogen forslag til forbedring ?

    mvh

    Peter Hesselager

    8. november 2010 14:39

Svar

  • Hej Peter,

    Problemet skyldes ikke C5, men Opportunistic Locking (OL), som er en del af operativsystemet.
    OL har gennem tiden befundet sig stort set befundet sig på samme versionsnummer.
    Der blev i Windows Vista/Windows Server 2008 introduceret en ny version med henblik på at kunne opnå større performance, men denne version er revideret siden.
    Derfor vil det først være fra Windows 7/Windows Server 2008 R2, og når alle klienter/servere kører disse operativsystemer, at man vil kunne opnå en netværks-performance ved fildeling, som er væsentlig bedre, end hvad vi oplever i dag.

    Nedenfor er forsøgt indsat en analyse vi i C5 Teamet tidligere har lavet af dette problem.
    (Det ser ud til at billederne ikke kommer med.)

    Artiklen er nu opdateret med de maksimale 2 billeder, som er tilladt i forummet. (28/3-2014)

    C5 performance problem.

     

    Baggrund:

     

    I forbindelse med hosting af en 3Gb stor Native C5 4.0 installation oplever man store performance problemer ved tilgang til bestemte kartoteker, når mere end 1 bruger er logget ind i C5. Repro scenariet er opslag på Varerabat fra Debitorer.

    Opportunistic Locking (OL) mistænkes for at være skyld i performance problemet. OL håndhæves af netværksklientdelen (redirector) på server og klient, og kan/skal under normale forhold ikke påvirkes direkte af klient applikationer.

     

    Observationer:

     

    På en Microsoft Dynamics C5 2008 installeret på en Windows Server 2008 RC0 er der oprettet > 200.000 debitorer i kartoteket CustTable og > 200.000 Kreditorer i kartoteket VendTable. C5 installationen tilgås af henholdsvis én eller to Vista klient maskiner.

     

    Ved hjælp af en simpel XAL kørsel fremsøges 10.000 poster i kartoteket CustTable med eller uden indeks.

     

    INT &starttime

    INT &endtime

     

    SET &starttime = TimeNow()

    PRINT "Starttime: " + Int2Str(&starttime)

    SEARCH CustTable //USING AccountIdx

    WHERE Account > 'Cust50000' AND Account <= 'Cust60000'

    END

    SET &endtime = TimeNow()

    PRINT "Endtime:   " + Int2Str(&endtime)

    PRINT "Used time: " + Int2Str(&endtime-&starttime)

    PAUSE

     

     

    Nedenfor ses resultatet af kørsel med 1 bruger logget ind i C5, og 2 brugere logget ind i C5.

     

    Test

    Tid

    1 bruger – søgning uden index

    49 sek.

    1 bruger – søgning med index

    1 sek.

    2 brugere – søgning uden index

    332 sek.

    2 brugere – søgning med index

    10 sek.

     

    Nedenfor ses grafer for netværkstrafikken på klienten med 1 bruger (Figur 1), 2 brugere (Figur 2) eller 1 bruger, hvor nr. 2 bruger logger ind i C5 undervejs (Figur 3).

     
    Figur 1

    Figur 1 viser effekten af OL, når kun 1 bruger tilgår filerne. Hvis søgningen løber til ende, og efterfølgende gentages, vil der anden gang, der søges, ikke blive trukket data fra serveren, da OL i denne tilstand tillader netværksklienten at cache alle filer i både read og write operationer. Bemærk den grønne graf, som indikerer udgående netværkstrafik.

    Figur 2 viser effekten af OL, når 2 brugere er logget ind i C5, og den ene udfører den ovennævnte søgning. Da C5 ved skrivning til applikationsfiler eller Native database sætter låsninger på filer, brydes den oplock, som netværksklientdelen (redirector) på server og klient administrerer. OL opererer nu i en anden mode, som kun under visse omstændigheder tillader read og write caching. Samtidig med at læse performance reduceres drastisk, introduceres der samtidig et overhead i form af udadgående netværkstrafik, som relaterer til OL kommunikation mellem klient- og server-redirector. I dette eksempel udgør denne kommunikation ca. halvdelen af båndbredden. I eksemplerne kan det ses at CPU ikke umiddelbart er en begrænsende faktor idet CPU ligger på ca. 80 % i 1 bruger scenariet og en anelse lavere i 2 bruger scenariet.


    Figur 3

    Figur 3 viser en kombination, hvor 1 bruger starter søgningen, og hvor nr. 2 bruger logger ind i C5 undervejs, men ikke foretager sig noget.
    Her ses tydeligt det store fald i performance.

     

     

    Ved hjælp af 2 små C++ programmer er det lykkedes at påvise at problematikken ikke er specifik for C5/XAL Native installationer.

     

    Et program genererer en vilkårlig stor fil med tilfældige tegn. Et andet program læser førstnævnte fil i blokke af valgt størrelse. Det kan endvidere vælges hvor meget af filen, som skal læses, og om man ønsker at låse 1 byte i filen på et valgt offset inde i filen.

     

    Af nedenstående Figur 4 – Figur 6 kan ses at blok (record) størrelsen kan virke begrænsende på performance, såvel som at CPU også er en begrænsende faktor (CPU 100 %).

     

    I Figur 7 ses et billede, som svarer godt til C5 problematikken i Figur 3 – OL overhead er dog mindre en ved C5 testen. Dette kan skyldes at en Native database ofte vil være fragmenteret, og datarecords derfor ikke nødvendigvis kan læses i sammenhængende blokke.

     

     

    Figur 4 - 1User 64kb LocksNo

    Figur 5 - 1User 128kb LocksNo

    Figur 6 - 1User 256kb LocksNo

    Figur 7 - 2Users 512kb LocksYes

     

    Der er ved ovenstående tests ikke fundet en forklaring på hvorfor netværksydelse falder så drastisk, når mere end 1 bruger tilgår filer på serveren. Når ovenstående tests udføres af 2 brugere samtidigt opnår hver bruger/klient tilnærmelsesvis samme netværksydelse, selv ved store forskelle i CPU og RAM bestykning. Dette kunne tyde på at forhold i OL implementationen er afgørende for de observerede symmetriske lave netværksydelser.

    Hvis 2 brugere tilgår filer uden låsninger, ses et helt andet mønster med højere, men ikke nødvendigvis symmetriske netværksydelser.

    C5/XAL arkitekturen er designet som flerbruger program, og anvender ved skrivninger låsninger af 1 byte, som semafor i et transaktions system ved low level skrivning af records og i high level TTS ved låsning af kartoteker, for at sikre datakonsistens og samtidighed. Da låsninger af 1 byte tilsyneladende ikke kan observeres af de mmc snap-ins, som følger med Windows operativsystemerne, har det ikke været muligt at få præciseret, hvilke C5 filer, som alene ved opstart af C5 introducerer 1 byte låsninger, som får OL systemet til at bryde den OL modus, som enkeltbrugere opererer i.

    Der er undervejs testet en prototype kerne, som holder arkitekturens semafor låsninger i eksterne filer, men test af denne C5 kerne har resulteret i nøjagtig samme adfærd og målte tider i søgningen med eller uden indeks i CustTable.

    I C5/XAL skal der specielt ved performance problemer ved adgang til data gennem forms, overvejes om udsøgning af data i formen er optimal. I tilfældet med VareRabat, opbygges der i formen et temporært indeks, der henter alle records i tabellen, som der efterfølgende udsøges data i.

    Da svartider på det C5/XAL Native databaseformat stiger lineært med databasestørrelsen og svartider på SQL platformen tilnærmelsesvis er ens uafhængigt af databasestørrelse, har det længe været kendt og anbefalet at portering til SQL platformen skal overvejes, når Native databaser når 400 – 800 Mb i størrelse.

    Ved krav om høj performance også i tilgang til applikations filer (som i internt format også er Native databaser) bør C5/XAL installationen ligge lokalt i forhold til eksekveringsmiljøet. Dette kan på Windows platformen opnås ved anvendelse af dedikerede terminalservere kombineret med SQL databaser. Historisk set har dette også været anvendt i meget store XAL UNIX installationer.

     

    For yderligere information om OL kan henvises til:

     

    http://msdn2.microsoft.com/en-us/library/aa365713.aspx

    og

    http://msdn2.microsoft.com/en-us/library/aa302210.aspx

     

    mvh
    Henrik Hansen


    Venlig Hilsen Henrik Hansen Program Manager II Microsoft Dynamics C5 ------------------------------------------------------- This post is provided 'as is' and confers no express or implied warranties or rights.
    9. november 2010 05:43
    Ejer

Alle besvarelser

  • Tilretninger? Ændringer i rapporten? Er det en ren filserver uden SQL og uden Exchange? Er der sat brugerrettigheder op noget sted i jeres C5? Mvh Maria
    8. november 2010 19:24
  • Hej Peter,

    Problemet skyldes ikke C5, men Opportunistic Locking (OL), som er en del af operativsystemet.
    OL har gennem tiden befundet sig stort set befundet sig på samme versionsnummer.
    Der blev i Windows Vista/Windows Server 2008 introduceret en ny version med henblik på at kunne opnå større performance, men denne version er revideret siden.
    Derfor vil det først være fra Windows 7/Windows Server 2008 R2, og når alle klienter/servere kører disse operativsystemer, at man vil kunne opnå en netværks-performance ved fildeling, som er væsentlig bedre, end hvad vi oplever i dag.

    Nedenfor er forsøgt indsat en analyse vi i C5 Teamet tidligere har lavet af dette problem.
    (Det ser ud til at billederne ikke kommer med.)

    Artiklen er nu opdateret med de maksimale 2 billeder, som er tilladt i forummet. (28/3-2014)

    C5 performance problem.

     

    Baggrund:

     

    I forbindelse med hosting af en 3Gb stor Native C5 4.0 installation oplever man store performance problemer ved tilgang til bestemte kartoteker, når mere end 1 bruger er logget ind i C5. Repro scenariet er opslag på Varerabat fra Debitorer.

    Opportunistic Locking (OL) mistænkes for at være skyld i performance problemet. OL håndhæves af netværksklientdelen (redirector) på server og klient, og kan/skal under normale forhold ikke påvirkes direkte af klient applikationer.

     

    Observationer:

     

    På en Microsoft Dynamics C5 2008 installeret på en Windows Server 2008 RC0 er der oprettet > 200.000 debitorer i kartoteket CustTable og > 200.000 Kreditorer i kartoteket VendTable. C5 installationen tilgås af henholdsvis én eller to Vista klient maskiner.

     

    Ved hjælp af en simpel XAL kørsel fremsøges 10.000 poster i kartoteket CustTable med eller uden indeks.

     

    INT &starttime

    INT &endtime

     

    SET &starttime = TimeNow()

    PRINT "Starttime: " + Int2Str(&starttime)

    SEARCH CustTable //USING AccountIdx

    WHERE Account > 'Cust50000' AND Account <= 'Cust60000'

    END

    SET &endtime = TimeNow()

    PRINT "Endtime:   " + Int2Str(&endtime)

    PRINT "Used time: " + Int2Str(&endtime-&starttime)

    PAUSE

     

     

    Nedenfor ses resultatet af kørsel med 1 bruger logget ind i C5, og 2 brugere logget ind i C5.

     

    Test

    Tid

    1 bruger – søgning uden index

    49 sek.

    1 bruger – søgning med index

    1 sek.

    2 brugere – søgning uden index

    332 sek.

    2 brugere – søgning med index

    10 sek.

     

    Nedenfor ses grafer for netværkstrafikken på klienten med 1 bruger (Figur 1), 2 brugere (Figur 2) eller 1 bruger, hvor nr. 2 bruger logger ind i C5 undervejs (Figur 3).

     
    Figur 1

    Figur 1 viser effekten af OL, når kun 1 bruger tilgår filerne. Hvis søgningen løber til ende, og efterfølgende gentages, vil der anden gang, der søges, ikke blive trukket data fra serveren, da OL i denne tilstand tillader netværksklienten at cache alle filer i både read og write operationer. Bemærk den grønne graf, som indikerer udgående netværkstrafik.

    Figur 2 viser effekten af OL, når 2 brugere er logget ind i C5, og den ene udfører den ovennævnte søgning. Da C5 ved skrivning til applikationsfiler eller Native database sætter låsninger på filer, brydes den oplock, som netværksklientdelen (redirector) på server og klient administrerer. OL opererer nu i en anden mode, som kun under visse omstændigheder tillader read og write caching. Samtidig med at læse performance reduceres drastisk, introduceres der samtidig et overhead i form af udadgående netværkstrafik, som relaterer til OL kommunikation mellem klient- og server-redirector. I dette eksempel udgør denne kommunikation ca. halvdelen af båndbredden. I eksemplerne kan det ses at CPU ikke umiddelbart er en begrænsende faktor idet CPU ligger på ca. 80 % i 1 bruger scenariet og en anelse lavere i 2 bruger scenariet.


    Figur 3

    Figur 3 viser en kombination, hvor 1 bruger starter søgningen, og hvor nr. 2 bruger logger ind i C5 undervejs, men ikke foretager sig noget.
    Her ses tydeligt det store fald i performance.

     

     

    Ved hjælp af 2 små C++ programmer er det lykkedes at påvise at problematikken ikke er specifik for C5/XAL Native installationer.

     

    Et program genererer en vilkårlig stor fil med tilfældige tegn. Et andet program læser førstnævnte fil i blokke af valgt størrelse. Det kan endvidere vælges hvor meget af filen, som skal læses, og om man ønsker at låse 1 byte i filen på et valgt offset inde i filen.

     

    Af nedenstående Figur 4 – Figur 6 kan ses at blok (record) størrelsen kan virke begrænsende på performance, såvel som at CPU også er en begrænsende faktor (CPU 100 %).

     

    I Figur 7 ses et billede, som svarer godt til C5 problematikken i Figur 3 – OL overhead er dog mindre en ved C5 testen. Dette kan skyldes at en Native database ofte vil være fragmenteret, og datarecords derfor ikke nødvendigvis kan læses i sammenhængende blokke.

     

     

    Figur 4 - 1User 64kb LocksNo

    Figur 5 - 1User 128kb LocksNo

    Figur 6 - 1User 256kb LocksNo

    Figur 7 - 2Users 512kb LocksYes

     

    Der er ved ovenstående tests ikke fundet en forklaring på hvorfor netværksydelse falder så drastisk, når mere end 1 bruger tilgår filer på serveren. Når ovenstående tests udføres af 2 brugere samtidigt opnår hver bruger/klient tilnærmelsesvis samme netværksydelse, selv ved store forskelle i CPU og RAM bestykning. Dette kunne tyde på at forhold i OL implementationen er afgørende for de observerede symmetriske lave netværksydelser.

    Hvis 2 brugere tilgår filer uden låsninger, ses et helt andet mønster med højere, men ikke nødvendigvis symmetriske netværksydelser.

    C5/XAL arkitekturen er designet som flerbruger program, og anvender ved skrivninger låsninger af 1 byte, som semafor i et transaktions system ved low level skrivning af records og i high level TTS ved låsning af kartoteker, for at sikre datakonsistens og samtidighed. Da låsninger af 1 byte tilsyneladende ikke kan observeres af de mmc snap-ins, som følger med Windows operativsystemerne, har det ikke været muligt at få præciseret, hvilke C5 filer, som alene ved opstart af C5 introducerer 1 byte låsninger, som får OL systemet til at bryde den OL modus, som enkeltbrugere opererer i.

    Der er undervejs testet en prototype kerne, som holder arkitekturens semafor låsninger i eksterne filer, men test af denne C5 kerne har resulteret i nøjagtig samme adfærd og målte tider i søgningen med eller uden indeks i CustTable.

    I C5/XAL skal der specielt ved performance problemer ved adgang til data gennem forms, overvejes om udsøgning af data i formen er optimal. I tilfældet med VareRabat, opbygges der i formen et temporært indeks, der henter alle records i tabellen, som der efterfølgende udsøges data i.

    Da svartider på det C5/XAL Native databaseformat stiger lineært med databasestørrelsen og svartider på SQL platformen tilnærmelsesvis er ens uafhængigt af databasestørrelse, har det længe været kendt og anbefalet at portering til SQL platformen skal overvejes, når Native databaser når 400 – 800 Mb i størrelse.

    Ved krav om høj performance også i tilgang til applikations filer (som i internt format også er Native databaser) bør C5/XAL installationen ligge lokalt i forhold til eksekveringsmiljøet. Dette kan på Windows platformen opnås ved anvendelse af dedikerede terminalservere kombineret med SQL databaser. Historisk set har dette også været anvendt i meget store XAL UNIX installationer.

     

    For yderligere information om OL kan henvises til:

     

    http://msdn2.microsoft.com/en-us/library/aa365713.aspx

    og

    http://msdn2.microsoft.com/en-us/library/aa302210.aspx

     

    mvh
    Henrik Hansen


    Venlig Hilsen Henrik Hansen Program Manager II Microsoft Dynamics C5 ------------------------------------------------------- This post is provided 'as is' and confers no express or implied warranties or rights.
    9. november 2010 05:43
    Ejer
  • Jeg har et problem som minder meget om dette, jeg har beskrevet det i et andet indlæg her : http://social.microsoft.com/Forums/da-DK/c5/thread/0e2cb015-7e1f-43bd-be33-8e7f174edf57

    Jeg vil være meget taknemlig hvis I som har skrevet i dette indlæg vil kaste et blik på det...

    16. marts 2011 09:57