How Speed and bandwidth affect performance in Axapta

How speed and bandwidth affect performance in Axapta

Bandwidth is the amount of data that can pass from the source to the destination per unit of time, averaged over many transactions. Measurement in mega bits per second (Mbps)/kilo bits per second (kbps).

Keep in mind that bandwidth is not a measure of speed, but rather of quantity.

If you look at your connection to the AOS as a freeway, bandwidth is a measure of the number of lanes available for traffic. The more lanes you have the greater the number of cars your freeway can handle.

Please keep in mind that bandwidth is not everything. Latency, "the speed", also matters.

Latency, is the time it takes for a single data transaction to occur -- the time between sending the data on the source end and its reception on the far end. Measurement is in millisecond, ‘ms’.

The speed on your freeway would be measured in the speed the cars traveled, and would be independent of the number of lanes available, (bandwidth). Speed on the network/Internet is determined by a measurement called "latency."

Simply put, latency measures the minimum amount of time possible for a packet to be transferred over your connection. The higher the latency gets the longer transfers take and the lower your connection "Speed Limit" will be.

This means that there will always be a minimum time that you can never beat. This is the latency. Even if you send a very small packet, the fastest it can get to the server will depend on the latency and not the bandwidth (if you have enough bandwidth for the packet).

So the perception of speed, is actually a combination of these two performance numbers.

The ping command can inform you about the latency on the network from your client to the AOS in ms. A more accurate way is to use the built in performance measurement tool in Axapta 2.5. (Administrator Inquiries Performance Tests Performance Tests Client/Server connection.) If the network has a high load of traffic, there is a possibility that the lower prioritized ICMP packet will indicate higher latency than there is on the network.
This is due to the fact that the ICMP packet used in combination with the ping command has a lower status on the network than the TCP packet.

What about the ASU?

Microsoft has defined the following:

1 ASU is the load generated by Axapta 2.5 when creating and invoicing the amount of 10 salesorders with 5 orderlines per salesorder, processed over the period of 1 hour. That's a total of 10 Salesorders with a total of 50 saleslines in one hour.

Go to http://technet.navision.com/ and see the article entitled 'ResourcesHardware Sizing Guide' about the definition of ASU. Please also read about the number of ASU the different Axapta modules produce. (Registration is required to access Damgaard TechNet.

How does all the above relate to the AOS?

With the above definition of ASU and demand for bandwidth and latency, and not at all having discussed the need for hardware, Microsoft a/s on the standard Axapta 2.5 gives the following rule of thumb that:

1 ISDN 64kbps is able to handle the throughput of 10 ASU, meaning that you e.g. can produce 100 salesorder with a total of 500 saleslines over a period on 1 hour.

The demand for latency has to be <100ms and preferably <50ms on the communication line.

Note The current latency requirement for Microsoft Dynamics AX 3.0 and for Microsoft Dynamics 4.0 SP1 is <5ms.

When the latency is high, it has a huge impact on the speed of the system.

Development gives the following formula to compute the bandwidth requirements.

The formula

ASU x 6,4 kbps = y
If y < 64 kbps then bandwidth = 64 kbps
else bandwidth = y kbps

Example:

The requirement for bandwidth by the load of 20 ASU
20 x 6,4 kbps = 128 kbps
Required bandwidth = 128 kbps

Keep in mind that the above has been tested on a standard Axapta 2.5 installation. If you have been adding to the standard application you have to consider the impact of this.

Recommendations

These can be rule of thumb only so please apply your common sense when sizing for a customer.

When talking bandwidth and latency requirements, you will need to agree to a performance level for Axapta with your customer.

Make sure that the bandwidth and latency are measured using Axapta's built-in tool rather than relying on what the network provider promises and measure it periodically over a period of time and particularly at peak hours to ensure that you know what the user will experience. Also make sure that the measurements are done on the production environment with as realistic a load as possible. It is of little value to measure one client loading a line that has to provide for 100.

Preferably Axapta should have a dedicated line to avoid mail, print etc. generating inexplicable sporadic bad performance. If this is not possible, make sure that the connection amply sized.

Keep in mind that due to the client/server architecture of Axapta, Axapta is hit very hard from high latency.

What about the future?

In the future, Microsoft has plans to produce some more detailed information in regard to the AOS communication and different types of communications lines.