Blog

március 17, 2014

egy másik felhasználó által lezárt asztal? Lassú teljesítmény? Ez csak néhány olyan kérdés, amely gyakran arra készteti az ügyfeleket, hogy kinőtték a Microsoft Dynamics NAV rendszerüket. Végül is ez a marketing üzenet: A Dynamics NAV kis-és középvállalkozások számára készült, így nyilvánvalóan nem képes nagyszámú felhasználót vagy nagy tranzakciós volument támogatni. Azért vagyok itt, hogy elmondjam, ez nem mindig így van.

NAV 2009 Classic vs.NAV 2013 RTC

a natív adatbázis klasszikus kliense villámgyors volt. De a valóság az, hogy a RoleTailored kliens (RTC) az SQL Serverrel gyorsabb. Független ellenőrzések (olvasni, nem Microsoft marketing anyag) bizonyítja ezt ki.A NAV 2013 RTC nagyjából 30 százalékkal gyorsabb, mint a natív adatbázisban szereplő NAV 2009 Classic kliens, és 500 százalékkal gyorsabb, mint a NAV 2009 RTC. Azok számára, akik még mindig nem ismerik az RTC-t, ez egy szerver oldali megoldás. Ez azt jelenti, hogy az összes kód a szerver oldalon fut. A klasszikus kliens egy kliens oldali alkalmazás volt, ami azt jelenti, hogy minden adatnak oda-vissza kellett mennie a kliens és a szerver között minden alkalommal, amikor egy kódsornak szüksége volt rá, lelassítva az alkalmazást. Ha valaha is megpróbálta használni a klasszikus klienst otthonról, akkor tudja, miről beszélek. A NAV szolgáltatási szinttel megnövekedett a gyorsítótár hatékonysága is. Korábban a Dynamics NAV az összes gyorsítótárazáshoz az SQL Serverre támaszkodott. A NAV 2009 szolgáltatásszintjének bevezetésével minden felhasználó lehetőséget kapott arra, hogy külön, privát gyorsítótárat tartson fenn a nemrégiben elért adatokhoz. A NAV 2013 bevezetett egy globális gyorsítótárat, amelyet nem csak a felhasználók osztanak meg, hanem szinkronizálva van a NAV szerverek között is. Alapvetően három gyorsítótár-szint van, amelyek megakadályozzák, hogy ezeket a költséges lemezolvasásokat elvégezzék. NAV 2013 is bevezetett feldolgozási sorban kiküldetés. Az asztal zárolása nem megy el, és soha nem is fog, de csökkentheti a felhasználók által tapasztalt zárak számát. Ezt lényegében úgy teszi, hogy csak egyet engedélyez, automatizált felhasználó posztolni. Mivel ez a felhasználó az egyetlen felhasználó, aki írhat a táblákba, a zárolás lehetetlen. Amikor a felhasználó a “Post” gombra kattint, ahelyett, hogy ténylegesen közzétenné, a rendszer egyszerűen egy rekordot ír egy sorba, hogy az automatizált felhasználó végrehajtsa. ArcherPoint végre egy egyéni megoldás erre a folyamatra NAV 2009 egy ügyfél, hogy kiküldetés 50.000 + tranzakciók naponta csúcsidőszakban. Nulla asztali zárakat tapasztaltak. Most ez a funkció kijön a dobozból.

a jövő

a Microsoft folyamatosan javítja a teljesítményt. A NAV telepítése az Azure-on lehetővé teszi, hogy több száz felhasználót kezeljen egyetlen kiszolgálón. Ahogy tovább halad ezen az úton, a Microsoft alacsonyan akarja tartani az adatközpontok hardverköltségeit, és ennek egyetlen módja a szolgáltatási szint teljesítményének javítása. Az SQL Server csapata is javításokat végez, bár nem világos, hogy a NAV hogyan fogja a legjobban kihasználni őket. Az új verziók lehetővé teszik, hogy a táblák és indexek kizárólag a memóriában éljenek. Soha nem kell olvasni a lemezről néhány dolgot a rendszer használata közben. Még gyorsabb, szilárdtestalapú lemezek esetén is a közvetlen memória-hozzáférés mindig gyorsabb lesz. Ha engem kérdezel, a jövő soha nem tűnt fényesebbnek a nagyvállalatok és a Dynamics NAV számára. Ez az egyik leginkább skálázható megoldás a piacon. Vállalkozásunk mindig növekszik, de szinte lehetetlen a NAV-ból kinőni. Ha további kérdései vannak a Microsoft Dynamics NAV megoldásának skálázhatóságával kapcsolatban, vagy fontolgatja vállalata számára, kérjük, lépjen velünk kapcsolatba az ArcherPoint címen. Örömmel megbeszéljük céljait és követelményeit, és segítünk meghatározni a legjobb utat. A Microsoft Dynamics NAV fejlesztésével kapcsolatos további információkért olvassa el az ArcherPoint fejlesztői blogot, amelyet kifejezetten a Dynamics NAV fejlesztői számára írtak.