Blogg

17. Mars 2014Microsoft Dynamics NAV Skalerbarhet: NAV 2009 Classic vs NAV 2013 RTC

Innsendt Av Matt Traxinger

Tabell låst av en annen bruker? Treg ytelse? Dette er bare et par problemer som ofte gjør at kundene tror at De har vokst Ut Av Deres Microsoft Dynamics NAV-system. Tross alt er det markedsføringsbudskapet: Dynamics NAV er for små og mellomstore bedrifter, så det kan åpenbart ikke støtte et stort antall brukere eller høyt transaksjonsvolum. Jeg er her for å fortelle deg at det ikke alltid er tilfelle.

NAV 2009 Classic vs. NAV 2013 RTC

Den Klassiske Klienten på den opprinnelige databasen var lynrask. Men virkeligheten er at Den Rolletilpassede Klienten (RTC) med SQL Server er raskere. Uavhengige verifikasjoner (les, ikke Microsoft markedsføringsmateriale) beviser dette.NAV 2013 RTC er omtrent 30 prosent raskere ENN Nav 2009 Classic-Klienten på Den Opprinnelige Databasen og 500 prosent raskere ENN NAV 2009 RTC. For de av dere som fortsatt ikke er kjent MED RTC, er det en server side løsning. Det betyr at alle koden utføres på serversiden. Den Klassiske Klienten var en klientside applikasjon, noe som betyr at alle dataene måtte gå frem og tilbake mellom klienten og serveren hver gang en linje med kode trengte det, sakker applikasjonen ned. Hvis Du noen gang har prøvd Å bruke Den Klassiske Klienten hjemmefra, vet du hva jeg snakker om. DET har også vært økt caching effektivitet MED NAV Service Tier. Tidligere stolte Dynamics NAV PÅ SQL Server for alle caching. Med innføringen AV tjenestenivået I NAV 2009 fikk hver bruker muligheten til å opprettholde en egen, privat cache for data som nylig ble åpnet. NAV 2013 introduserte en global cache som ikke bare deles av brukere, men også synkroniseres på TVERS AV NAV-servere. Det er i hovedsak tre cache nivåer for å holde deg fra å måtte utføre de kostbare disk leser. NAV 2013 introduserte også en behandlingskø for postering. Tabelllåsing går ikke bort og vil aldri, men du kan redusere antall låser brukerne møter. Du gjør dette i hovedsak ved bare å tillate en enkelt, automatisert bruker å poste. Siden brukeren er den eneste brukeren som kan skrive til tabellene, låser er umulig. Når en bruker klikker på “Post”, i stedet for å faktisk legge inn, skriver systemet bare en post til en kø for den automatiserte brukeren å utføre. ArcherPoint implementert en tilpasset løsning FOR DENNE prosessen FOR NAV 2009 for en kunde som var postering 50,000 + transaksjoner per dag i høysesongen. De opplevde null bordlås. Nå kommer denne funksjonaliteten ut av boksen.

Fremtiden

Microsoft gjør stadig forbedringer når det gjelder ytelse. Distribusjonen AV NAV på Azure gir it muligheten til å håndtere hundrevis av brukere på en enkelt server. Som Det fortsetter nedover denne veien, Vil Microsoft ønske å holde maskinvarekostnadene for datasentrene nede, og Den eneste måten å gjøre det på er å fortsette å forbedre ytelsen til servicenivået. SQL Server-teamet gjør også forbedringer, selv om DET ikke er klart hvordan NAV best vil utnytte dem ennå. Nye versjoner vil tillate tabeller og indekser å leve utelukkende i minnet. Du trenger aldri å lese fra disk for noen ting mens du bruker systemet. Selv med raskere, solid state-disker, vil direkte minnetilgang alltid være raskere. Hvis du spør meg, har fremtiden aldri sett lysere ut for store selskaper og Dynamics NAV. Det er en av de mest skalerbare løsningene på markedet. Våre virksomheter vokser alltid, men DET er nesten umulig å vokse UT AV NAV. Hvis du har flere spørsmål om skalerbarheten Til Din Microsoft Dynamics NAV-løsning eller vurderer det for din bedrift, vennligst kontakt Oss På ArcherPoint. Vi vil gjerne diskutere dine mål og krav og hjelpe deg med å finne den beste veien. For mer informasjon om emner relatert Til Microsoft Dynamics NAV-utvikling, les ArcherPoint Developer Blog, skrevet spesielt for Dynamics NAV-utviklere.

Leave a Reply