blogg

Mars 17, 2014 Microsoft Dynamics NAV skalbarhet: NAV 2009 Classic vs NAV 2013 RTC

inskickat av Matt Traxinger

tabell låst av en annan användare? Trög prestanda? Det här är bara ett par problem som ofta får kunder att tro att de har odlat sitt Microsoft Dynamics NAV-system. Det är trots allt marknadsföringsbudskapet: Dynamics NAV är för små till medelstora företag, så det kan uppenbarligen inte stödja ett stort antal användare eller hög transaktionsvolym. Jag är här för att säga att det inte alltid är fallet.

NAV 2009 Classic vs. NAV 2013 RTC

den klassiska klienten på den ursprungliga databasen var blixtsnabb. Men verkligheten är att RoleTailored Client (RTC) med SQL Server är snabbare. Oberoende verifieringar (läs, inte Microsoft marknadsföringsmaterial) bevisar detta.NAV 2013 RTC är ungefär 30 procent snabbare än NAV 2009 Classic-klienten på den ursprungliga databasen och 500 procent snabbare än NAV 2009 RTC. För er som fortfarande inte känner till RTC är det en serversidan lösning. Det betyder att all kod körs på serversidan. Den klassiska klienten var en klientsidan ansökan, vilket innebär att alla data var tvungen att gå fram och tillbaka mellan klienten och servern varje gång en rad kod behövs det, bromsa programmet ner. Om du någonsin har försökt använda den klassiska klienten hemifrån, vet du vad jag pratar om. Det har också ökat caching effektivitet med NAV Service Tier. Tidigare förlitade sig Dynamics NAV på SQL Server för all cachning. Med introduktionen av service tier I NAV 2009 fick varje användare möjlighet att upprätthålla en separat, privat cache för data som nyligen hade nås. NAV 2013 introducerade en global cache som inte bara delas av användare utan också synkroniseras över NAV-servrar. Det finns i huvudsak tre cache-nivåer för att hålla dig från att behöva utföra de kostsamma diskläsningarna. NAV 2013 introducerade också en bearbetningskö för utstationering. Bordslåsning går inte bort och kommer aldrig att göra det, men du kan minska antalet lås som dina användare stöter på. Du gör detta i huvudsak genom att bara tillåta en enda, automatiserad användare att posta. Eftersom den användaren är den enda användaren som kan skriva till tabellerna är lås omöjliga. När en användare klickar på “Post”, istället för att faktiskt posta, skriver systemet helt enkelt en post till en kö för den automatiserade användaren att utföra. ArcherPoint implementerade en anpassad lösning för denna process för NAV 2009 för en kund som publicerade 50 000+ transaktioner per dag under högsäsong. De upplevde noll bordslås. Nu kommer denna funktionalitet ut ur lådan.

framtiden

Microsoft gör ständigt förbättringar när det gäller prestanda. Implementeringen av NAV på Azure ger den möjlighet att hantera hundratals användare på en enda server. När det fortsätter på den här vägen kommer Microsoft att vilja hålla hårdvarukostnaderna för datacentren nere, och det enda sättet att göra det är att fortsätta förbättra service tier prestanda. SQL Server-teamet gör också förbättringar, även om det inte är klart hur NAV bäst använder dem än. Nya versioner gör det möjligt för tabeller och index att leva uteslutande i minnet. Du behöver aldrig läsa från disken för vissa saker när du använder systemet. Även med snabbare solid state-skivor kommer direkt minnesåtkomst alltid att bli snabbare. Om du frågar mig har framtiden aldrig sett ljusare ut för stora företag och Dynamics NAV. Det är en av de mest skalbara lösningarna på marknaden. Våra företag växer alltid, men det är nästan omöjligt att växa ur NAV. Om du har ytterligare frågor om skalbarheten för din Microsoft Dynamics NAV-lösning eller funderar på det för ditt företag, kontakta oss på ArcherPoint. Vi diskuterar gärna dina mål och krav och hjälper dig att bestämma den bästa vägen. För mer information om ämnen relaterade till Microsoft Dynamics NAV-utveckling, läs ArcherPoint Developer Blog, skriven speciellt för Dynamics NAV-Utvecklare.

Leave a Reply