Options

MSMQ, NAS and ASP.Net Performance Questions?

jrlandeenjrlandeen Member Posts: 4
edited 2005-08-05 in Navision e-Commerce
I'm beginning a .Net development project with Navision
and I am looking for more information on benchmarks and
best practices (as MS doesn't appear to have any guidelines on this at all)

We're looking at basing our architecture and approach on
using Microsoft Message Queue (MSMQ) and Navision
Application Server (NAS) with a ASP.Net front end. (based
on the following document: .NET Development with Navision
from Patrice Dupont-Roc @ Microsoft - May 7, 2004). This is a similar approach to the Say Hello to Navision and Have it say Hello politely help article.

We've run some initial tests and have proven that this
does actually work. However there are some concerns on
our team about performance. It's easy to get a small
customer list, it is another thing to filter, analyze and
work with transaction related data. Are there any
benchmarks on the number of messages, size of messages or
other important measures that have been documented? Are
there any active sites with a large user base accessing
Navision data in this manner?

Any help, suggestions or guidance would be greatly
appreciated.

Jeff L.

Comments

  • Options
    SkeeveSkeeve Member Posts: 33
    I have had some performance problems especially around very large XML files in DomDocuments.

    The actual performance of MSMQ is very good.

    We have recently integrated a warehouse management system via XML and MSMQ and that thing can process several hundred messages in just a few seconds.

    Of course there's always the locking problem. NAS is handled just like a regular client. So if it tried to read a table that is currently locked, your web front end would just sit there and wait for a response.

    Depending on what you are trying to do, I would think about using a SQL server in between NAS and Navision and syncronize the data you need. That architecture would minimize the impact on Navision.
Sign In or Register to comment.