Hi,
I have added to the download sections test results for “Locking Management Solution”. It solves most common performance and locking issues in NAV. On our website you also can see live recording of the test with user experience…
Enjoy life without locking and performance issues!!!
Well, well … that’s some sort of promise … and so decent and humble … “lock FREE navision” … “NEVER performance issues” … I wish if that was true …
First thing: your download is broken, the PDF I get is invalid/corrupt. When looking at your webpage I cannot find out which company your are (are you a real company? Or are you just (ab)using the MS Dynamics logo there? No clue about the person(s) behind this “great promise” …
My personal and humble opinion: I’m dealing with NAV/SQL performance issues - including blocking problems, of course - for years and I am conviced that is impossible to create a “completely block free NAV”, as this is technically impossible! It might be possible to reduce the number of blocks - that’s what the seriously working people do - but you will never get rid of them all … if there were NO performance issues with NAV, well, then it would not be NAV anymore (at least NAV as we know it) …
So I simply do not believe in your “miraculous software which is supposed to fix it all within an instant”! If this isn’t a lie then at least it is some kind of hoax or tremendous exaggeration [:@]
I would gladly retreat this statement if you could give proof of your promisies, so please make your download work and enlighten us with further (technical) details how you could “make possible the impossible” …
Kind regards,
Jörg
Hi Jorg,
Sorry if you could not load pdf… It has all details and comparison with standard NAV. If you load you will see what we actually did and what you can expect from the solution…
As of company - we are formed (and became NSC - so no abuse of logo) in the 2002 and working with NAV (actually started with Navigator in DOS) since 1998… We are Microsoft contractor and was involved in developing Russian version of NAV. Now we are working as development partner for US and eastern europe countries.
I understand that you do not know my name but this is not important… This is work of the team of people and i do not want take all credit for the work…
As of impossibe to create “completely block free NAV” you are right… and whitepaper explains what kind of locks we experiencing and why we name it “locking free”.
If anybody has problem with loading PDF please, let me know. I tried and it was fine… Also some people have contacted me and it looks like they did not have any problem.
Hi Jorg,
You are right. some more people had problem with viewing the file. I have recreated it and now it should be ok…
Nikolay
First: I still cannot download this PDF.
And: So if you are a legal MS/Dynamics partner, so why don’t you show any names (e.g. general manager, owner of the company) or contact data (e.g. company’s location, subsidiaries) and all the other stuff which is supposed to be found on a MS partner webpage?
And if you are such an “experienced” company, why have you opened your webspace just 3 days ago (see http://www.nic.com/nic/whois/)?
And when searching for “Thrifty Software Building Team” in the MS partner directory I find a company named “Lean4systems Group” which seems to be somehow related to you …
Strange, strange, strange … [*-)]
But then again: I would realy appreciate if you could share your precious knowledge about how “you help to do impossible” (your company motto!) - looking forward to that!
My name is Valentin Gvozdev and I am one of the owners of the Thrifty Software Building Team… This is our development company and we never needed website because we were never working with clients directly through this company. Lean4Systems is the parent company that does implementations and actually works with customers.
I do not understand why you cant load PDF (I will send it to you directly). Actually it looks like you kind of annoyed that such solution can exist. It is true - we can threat business model for companies like yours, SQL Sunrise, SQL Perform… But believe me it still a lot of work to make it work and you will not stay without work it you will partner with us…
The solution is quite elegant and as anything in NAV world is easy to repeat – so do not expect me just tell everybody how to do it here. At the end we spend 2 years working on it and to say honestly i have not believed myself until I saw result.
Hi Val,
So it’s YOU who is behind! I was starting to wonder what you were up to, we haven’t seen much to you here the last 5 months. And it’s quite a few years ago since you, me and David Singleton worked together in New York!
I have been able to download your PDF with no problems.
I think it your product sounds fanatastic, and I sure understand why Jôrg is reacting as he is. I as thinking the same, until you showed up. But I would really like to hear more about it. Maybe get a few customer references!
Hi Jorg,
I have looked at your website and I think I understand now why you think that this is not possible. I have found document - Performance Checklists 1.04.pdf where you list performance indicators that people should control to improve performance. For SQL Locks you have only two: Lock Waits/sec and Number of Deadlocks/sec
Both of them kind of irrelevant for performance optimization… Number of deadlocks shoes how good is the Navision code - so it king of easy to correct by following standard rules. Lock Waits/sec - is irrelevant because with number of users number of locks will grow and this is absolutely normal if average lock time is not growing.
From our point of view the important indicators are: Avg. Lock Time and Lock Wait Time (ms) - in our document we name it Total Lock Time per Second.
In Standard NAV these indicators growing very fast as number of users increases… As you can see standard NAV (without optimizations and our hardware) can handle only 4 users working simultaneously… As example Avg. Lock Time for 10 users is 1060 ms, for 20 - 2782 ms, for 40 - 6104 ms…
In our solution Avg. Lock Time stays the same independently from number of users - around 50 ms. With this Avg. Lock Time user will not experience any delay in day to day operations. (You can see video on our website with user experience test…). That’s why we name it “Locking Free” - based on the user experience.
My guess that if you not tring to minimize this to performance indicators you just not fighting real problem. And if you not fighting real problem you will believe that it is impossible to solve it. (On other hand you maybe just not to put these indicators because you do not want your competitors to know what real problem is). It would be very interesting to know what you can do best with your methods of optimization for this two performance indicators on standard NAV 2009.
Hi Erick,
We actually be able to finish it this New Years eve. Thank you to crisis - lots of free time.
We planning to do first cliend with David and also i asked Microsoft to test in there lab for couple of thousand users. But actually looks very promising… I tired to loose projects to AX because of scalability.
Hi Valentin,
first: thanks for sending me the PDF … I don’t know why I couldn’t download it …
Well, I have to agree with Erik, since you showed up here I feel also more confident with this “promise”. You know, my problem is, that there are way too many charlatans in this “NAV/SQL Perfomance Optimization” business with big-mothed promises claiming to have invented the “famous silver bullet to kill that bad bad bad perfomance monster”. And actually these kind of people are discrediting all those who are seriosly working on this issue.
Again, since you are involved I feel better about that.
So please be so kind and shar some of the technical aspecst behind this solution, I’m really really curious!
Kind regards,
Jörg
Hi Nikolay,
first I want to apologize for my somewhat harsh offences; the reasons for my concerns are stated in my reply to Valentin.
second: No, I don’t feel “threatened” by your solution, as my business model is actually to get rid of these perfromance issues. Doing so I’m always willing to learn and to improve simply to fix things! Actually, if things indeed work out as you promise I want to become your first reseller in D-A-CH [H]
Well, when it about the perfmon indicator I would like to say that is doen’t matter anyway, which counters you look at. “Locking” is a natural behaviour of every database, the issues we have to take care about are the resulting “blocks”! The counters just indicate a problem but do not tell anything about a problem or the reasons for it.
So I’m focusing in the blocks and deadlock we encounter (as described in my BLOG); here I could learn “who is blocking whom, on which resource, which satetement and which query plan was used, etc.”. Analyzing this data I make up my mind to find appropriate solutions - and there could be plenty: SIFT optimization, index/statistic optimization etc. - the SQL site stuff - and then the application site: C/AL code, filters, lockings, etc…
Once a solution has been implemented I could verify on basis of the blocks/deadlocks if it was succesful (or not).
I’m doing this (and much more) for quite a while and I think I know pretty much about what is possible or not. Thus, I’m still convinced it is impossible to make a NAV system completely (b)lock-free, but I know that it is possible to reduce the amount of problems remarkably by the right enhancements.
So please give us a “technical glimpse” on your solution and tell us what you are doing we weren’t able to do (so far).
Kind regards,
Jörg
Hi,
I think we have shown in the video what was actually done from technical point of view. We allow to process multiple transactions simultaniously… Look at item ledger entries - they are not sequential by Document No. they are mixed - one form one document, another from another… We have lock waits only when the same item get shipped on 2 different sales orders bacase the same applied entry has to be updated… This works on all entries - GL, value, Reservation…
Sorry, no details how we did it.
Not giving away your business secrets? [:P]
That’s it? Well, I suppose this is - at least most of your - “secret”:
When writing data you assign a GUID - or other sort of “random” - value (sort of “spacer”) to the record and base the “Clustered Index” on it. This will actually result in spreading the data on different physical pages, thus avoiding the ROW X/PAG IX problem. Prerequisite of this is to get rid of the old “Entry No” which is actually the biggest effort to implemet all this (and e.g. erasing the “Entry No.” in “G/L Entry” is sort of illegal in Germany, at least).
Further, this only works if the table is large enough to occupy enough pages, on small tables it doesn’t.
This or similar solutions are almost ancient and common practice with SQL Server for a long time, even I blogged about that almost one year ago.
Next challenge is “No. Series” - easiest way is to have separate “No. Series Line” tables for different purposes (expanding CU “No. Series Management” is somewhat tricky).
Add some index optimization, further C/AL improvements (e.g. getting rid of several LOCKTABLE, which you cannot in some case as this would jeopardize data-consitency, optimize some filters, etc.), run it on somewhat sufficient hardware - and voila!
Is that it? No more? I’m somewhat dissapointed … [:^)]
I know that implementig this stuff throughout a whole NAV is databse is a hell of effort, but I would never recommend to do that: You jeopardize any legal certifications, and upgrading to further versions will be hell.
I prefer implementig such things where they are really - specifically - needed, means where indeed blocking problems occured (I work with a scalpel, not with a sledgehammer).
Dont be dissapointed so fast. Actually nothing even close to what you have described… - entry number is sequential and only one table for “No. Series Lines”… We spend couple of years to come up with solution… Whatever you said we tried - did not work for different reasons…
GUID and RANDOM - because it has to be sequential for legal reasons… Separate “No. Series Line” does not help at all - it is the same reason Sales Invoice or Sales Shipment No.
so be it …
First of all thanks Jorg for his candid remarks - I want you to know that you didn’t sound overly passionate. Just like the rest of you I’m pretty skeptical about the claims here.
So I was brainstormign a bit how this could be possible, even in theory. I have an idea, but no notion of how I would actually implement it.
Basically, if you could intercept the SQL before it got to the server, you might be able to do some fun things. You could pool the queries, and then issue them in a blocking friendly way. You also might be able to refine the transaction level. I’m guessing in the three tier client, at least in theory, this is possible.
Hi Girish,
If you will give me problem that you trying to solve in theory i will let you know how it was solved in practice in 2 tier client.
Actually many people tell me about some problem that does not exist in our solution. I just not see it. Can you please poin me to the code that actually troubling you.
Thanks.
I haven’t seen how your solution works at all – I"m just guessing you leverage the the three tier system somehow.
No we did it in 2 tier. It will work in 5.00 SP1 also.
We just rewrote all code that responsible for locking based on the principles of parallel programming.
In two words – NAV uses LOCKTABLE as “Semaphore” and locks whole table for lens of the transaction. But you need to lock “Entry No. assignment” only for duration necessary to assign next Entry No.
We were able to create “Semaphore” and Assignment function that locks only for about 5 ms per Assignment transaction (entry no. or Document No.). After entry no. assigned another user can get next number. So you do not need LOCKTABLE or FINDLAST. All is done using standard NAV functionality in 2 tier environment.