Thought those math rules you learned in 6^thgrade were useless? Think again…some are more applicable to the architecture of your data center than you might think.

Remember back when you were in the 6^th grade, learning about the order of operations in math class? You might recall that you learned that the order in which mathematical operators were applied can have a significant impact on the result. That’s why we learned there’s an order of operations – a set of rules – that we need to follow in order to ensure that we always get the correct answer when performing mathematical equations.

Rule 1:   First perform any calculations inside parentheses.

Rule 2:   Next perform all multiplications and divisions, working from left to right.

Rule 3:   Lastly, perform all additions and subtractions, working from left to right.

Similarly, the order in which network and application delivery operations  are applied can dramatically impact the performance and efficiency of the delivery of applications – no matter where those applications reside.

Let’s do some math to prove our theory, shall we? Consider the following “table” of the time it takes to execute certain network operations. Note that these are completely arbitrary in that they do not represent actual performance statistics, though the values are relative to one another based on real metrics. The actual time to execute a given operation will be highly dependent on load and device performing the operation, thus it will be variable. However, what is static is that each operation will consume “time” on a given system to execute, and this table is designed to represent that basic truism.

Architecture #1

Let’s assume for a moment that our architecture is simple: two network devices, both will need to inspect the payload to apply security or routing policies, and an application. Assuming that the application is responsible for compression and SSL operations, this means that on the ingress (inbound) requests, both network devices must necessarily decrypt and then re-encrypt the request in order to apply policies. The application, because it is assuming it handled the SSL, also needs to decrypt.

Based on our completely arbitrary and fictitious table of operational costs, this means the time to execute on ingress is:

SSL: 25 units + Compression: 9 units + Inspection: 14 units = 48 units

and our total CPU cycle utilization is:

SSL: 50 units + Compression: 21 units + Inspection: 16 units = 87 units

On egress (outbound) our total time to execute will be:

SSL: 25 units + Compression: 15 units + Inspection: 14 units = 54 units

and total CPU cycle utilization at:

SSL: 50 units + Compression: 35 units + Inspection: 16 units = 101 units

Our total time to execute 1 transaction using this order of operations is 102 units with a total CPU cycle utilization of 188 units. Now let’s compare that with a more strict order of operations in the architecture, delegating responsibility for compression and SSL operations to Network Device #1.

Architecture #2

Let us now assume that we are moving those functions that must be repeated throughout the architecture closer to the “edge” of the flow of traffic such that we reduce the number of times the functions must be repeated due to the need to inspect data. Based on our completely arbitrary and fictitious table of operational costs, this means the time to execute using our new order of operations on ingress is:

SSL: 5 units + Compression: 3 units + Inspection: 14 units = 22 units

and our total CPU cycle utilization is:

SSL: 10 units + Compression: 7 units + Inspection: 16 units = 33 units

On egress (outbound) our total time to execute will be exactly the same:

SSL: 5 units + Compression: 3 units + Inspection: 14 units = 22 units

and our total CPU cycle utilization is:

SSL: 10 units + Compression: 7 units + Inspection: 16 units = 33 units

Our total time to execute 1 transaction using this order of operations is 44 units with a total CPU cycle utilization of 66 units. Let’s compare the two side by side:

That pretty much says it all. Note that we’re not comparing costs as the cost per “unit” to execute will vary from device to device, although it is almost certainly true that execution on the network device will cost more per “CPU cycle” than on the application server because network devices are usually more expensive. Note, however, that the time to execute and CPU cycles consumed does not reflect the fact that when executed on specialized hardware the processing is more efficient, so the total cost will likely not be too much higher because it’s offset by the reduction in number of cycles required.

Just as is true for mathematical operations the order in which capabilities are applied dramatically impacts the end result.

The point of this little exercise was twofold. First, it’s a reminder to pay attention to the application delivery architecture you are employing – no matter where it might be located. That means from point of ingress through the network to the application and back again. Every point at which packets and/or payloads must be inspected is a potential point at which the efficiency and performance of your application will be affected by the order in which application delivery security and acceleration policies are applied. Second, it’s to mathematically illustrate the impact of offloading compute intense calculations and processes such as SSL and compression to network-hosted application delivery platforms, especially those enabled with specialized hardware designed to improve the execution performance of such processes.

Now, given this data we should be able to abstract what we’ve learned into a basic set of rules regarding the application delivery network order of operations:

Rule 1:   Offload all cryptographic or obfuscating (like compression) functions to the last device in the delivery network which needs to inspect the payload to reduce the impact of redundant operations.

Well, there you have it. One simple rule takes care of the application delivery network order of operations. It’s more efficient, will be more cost effective, and in your application performance will thank you for it (because we all know your users won’t, even though they should).

Related blogs & articles: When Did Specialized Hardware Become a Dirty Word? Square Infrastructure Pegs Don’t Fit in Round Network Holes Virtual Network Infrastructure: Virtually Good Enough? I am wondering why not all websites enabling this great feature GZIP? Pay No Attention to the Infrastructure Behind the Cloudy Curtain The Devil is in the Details The Question Shouldn’t Be Where are the Network Virtual Appliances but Where is the Architecture? VM Sprawl is Bad but Network Sprawl is Badder A Green Architectural Strategy That Puts IT in the Black [PDF]