Options

NAS for posting invoices and payments

ArtursArturs Member Posts: 30
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?
Regards,
Arturs Gedvillo
CTO

Comments

  • Options
    jhoekjhoek Member Posts: 216
    A dedicated server will certainly help, as well as a fast network connection to the database server!
    Kind regards,

    Jan Hoek
    Product Developer
    Mprise Products B.V.
  • Options
    bbrownbbrown Member Posts: 3,268
    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.
    There are no bugs - only undocumented features.
  • Options
    jhoekjhoek Member Posts: 216
    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".
    Kind regards,

    Jan Hoek
    Product Developer
    Mprise Products B.V.
  • Options
    ArtursArturs Member Posts: 30
    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 ?
    Regards,
    Arturs Gedvillo
    CTO
  • Options
    bbrownbbrown Member Posts: 3,268
    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.
    There are no bugs - only undocumented features.
  • Options
    ArtursArturs Member Posts: 30
    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.
    Regards,
    Arturs Gedvillo
    CTO
  • Options
    bbrownbbrown Member Posts: 3,268
    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.
    There are no bugs - only undocumented features.
  • Options
    ArtursArturs Member Posts: 30
    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:
    Regards,
    Arturs Gedvillo
    CTO
  • Options
    bbrownbbrown Member Posts: 3,268
    Ok, this give me a better understanding of what you are trying to do.
    There are no bugs - only undocumented features.
  • Options
    ErichErich Member Posts: 2
    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.
  • Options
    DenSterDenSter Member Posts: 8,304
    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.
  • Options
    bbrownbbrown Member Posts: 3,268
    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.
    There are no bugs - only undocumented features.
  • Options
    ara3nara3n Member Posts: 9,255
    Also if NAS is run on same computer where the database server is. There is no network overhead. It runs a lot faster.
    Ahmed Rashed Amini
    Independent Consultant/Developer


    blog: https://dynamicsuser.net/nav/b/ara3n
  • Options
    kinekine Member Posts: 12,562
    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.
    Kamil Sacek
    MVP - Dynamics NAV
    My BLOG
    NAVERTICA a.s.
Sign In or Register to comment.