NAS for posting invoices and payments

Arturs

Have anybody tried to setup Application Server to post invoices and payments in the background.
The target is to avoid table locking for 70 concurent users. Will it help if NAS is installed on dedicated high performance server and does the posting while workstations only mark invoices to be posted?

jhoek

A dedicated server will certainly help, as well as a fast network connection to the database server!

bbrown

Is your plan to have NAS posting in realtime or to post during off-hours?

Using NAS to post will create the same table locks that a user does while posting.

jhoek

Not necessarily true. Seventy normal users may get "in each other's way" if they all post independently - one NAS will never get "in it's own way".

Arturs

My plan is to have NAS posting in realtime. NAS will do it in queue so no tablelocking should occur.
It's just in theory, wanted to hear someones experience on this.

BTW is it possible to view records of locked table ?

bbrown

Which database are you using?

Not necessarily true. Seventy normal users may get "in each other's way" if they all post independently - one NAS will never get "in it's own way".

NAS is just anoher user. It will lock the same tables during posting that a normal user would. One NAS would not get "in it's own way", but it could get in the way of normal users. No different from a normal user posting.

BTW is it possible to view records of locked table ?

With the native db, another user can view the latest committed version of the table's data.

With SQL, it depends on the transaction type.

Arturs

bbrown wrote:

Which database are you using?

Going to use SQL.

I want to achieve that users in 15 branches can post purchase invoices, item transfers and BOM journals without delays.

bbrown

Sql will have different locking behavior than the native db. However, NAS posting on SQL will create the same locks (and delays) as a normal user posting on SQL.

What do you mean by "without delays"?

Example 1:

A user creates a purchase invoice and post it. The posting takes 10 seconds. This means the user must wait at least 10 seconds before beginning to enter the next purchase invoice.

Example 2:

A user creates a purchase invoice and submits it to a queue for posting by NAS. The queue is processed by NAS on a FIFO basis. The invoice will take 10 seconds (maybe less if NAS on faster machine) to process when its turn comes up. But if 5 other invoices (same size) are already in the ueue, the this invoice will take 1 minute to post.

Arturs

In example 2, what user does is he marks the invoice to be posted. he doesn't know and care it's not posted yet. He can go on with the next invoice or whatever. And it's for all users the same. NAS does background posting and locks Entry tables, so it shouldn't slow down any user.

Maybe I should go more into details... :roll:

bbrown

Ok, this give me a better understanding of what you are trying to do.

Erich

Actually we are programming the same "3-tier" base on a big project with a lot of postings with sometimes 800 lines per Document and 100 concurrent User.

If all postings will be done from NAS than you can have following effects:

1. Postings are, depending on your network, 50% faster.
2. You must not use table lock if one NAS post all (SQL Server has its on locking rules). If you use no locking, SQL Server is faster.
3. You don't must search for the last entry no. use an alternate method like Single instance CU, where you save the last Entry no. for all Entry line types

All documents, where you have a header (Sales Header, Purchase Header,...are not the problem. The testing process must be splitted to ensure to have no errors during the posting process.

On the journals you should make your on header, where you can make your marks like "open", "Tested" (ready for posting).

I think it’s the only way, to have a high performance environment with a lot of "Working" user.

DenSter

Right, the NAS posting is so that all postings happen one after the other as opposed to a bunch of users fighting for the same resources. The posting itself still takes the same time, but because it's now done by a dedicated machine, it allows the human users to go on to the next task while the NAS is working its way through the queue.

Also, by using a server type machine, you have more power at your disposal, and it is just one network connection. It saves time all around, and I hear this approach has been used very successfully to solve performance (i.e. locking) problems.

bbrown

NAS can be a useful tool in high transaction systems. It can be used to offload processing from the users and allow them to move on to the next task.

NAS is usually run on a faster machine that has direct access to the network backbone. (resulting in better performance).

NAS does not have the overhead of a graphical interface (resulting in better performance).

NAS is useful if the goal is to free up the user to move onto the next process (ie. enter the next order, or pick the next order). However NAS will still access and lock the same resource that the client would, if other clients are attempting to access these resources (different functions) then NAS will not resolve the issue.

ara3n

Also if NAS is run on same computer where the database server is. There is no network overhead. It runs a lot faster.

kine

Of course, in some cases optimization of HW, keys and C/AL can be enough to have fast posting. Because: if you have no optimal HW (easy, can be cheap solution with big performance gain), posting is slow. If you have no optimal keys , there is big locking problem, optimize keys and you will have less locks (easy with Navision 4.01, much harder with previous versions, big performance gain). Optimize C/AL code (loops through dimensions, reading last entry no., reading setup tables in loops etc. - very hard, lower performance gain) and you will have better performance.