Transactional activity is increasing dramatically in networks and it is forcing a change in how they are designed. It is no longer sufficient to solely consider infrastructure design in terms of availability and bandwidth. It now requires a strong understanding of application performance and factors such as latency, loss and QoS. These greatly affect availability and bandwidth but,sadly, many designers are failing to keep up.

Gone are the days of simple web pages that load the principal text of the page with a few embedded graphics, and the static desktop or application which did not update until you pressed enter. Enter instead Web 2.0 sites and complex applications containing wonderful user features - for which read network challenges. The list of features to consider incudes:

- Multiple graphics or objects, some with active content

- Multiple css files

- Live tickers, RSS and Twitter feeds

- Widgets and Modules that independently update content (e.g. share prices)

- Adverts, both variable and context sensitive

- Multiple instances of tracking code (Google, Yahoo, Bing, Ask, Salesforce)

- Monitoring code (where the page contacts the site constantly to see what you're up to)

- Combo and list boxes (drop-down boxes) that are populated as you click them (JIT)

- Suggest/Search boxes (like Google Suggest) which change as you type

- Mouse-overs that load active content

- Ajax code.

Each one of these features creates multiple transactions. Some are triggered by user activity and some are automatic. Multiply this by the many users, sites, and apps updating, and you start to see the problem. Users of an Application Performance Management (APM) product quickly notice high volumes of solicited transactions taking place, but shockingly, it is the volume of unsolicited ones that surprise. We used an APM to monitor network traffic over the course of two hours. As you can see from the screen shot above, one web site has been visited more than 1500 times. In reality, the user visiting that site had left the page open in their browser and they were unaware that it was generating so many unsolicited network transactions.

Clearly these transactions consume valuable bandwidth, and that needs to be designed in. In addition, the high level of request and response packets can cause issues such as queuing and queue overflow and this impedes business application performance. This also needs to be designed in. These examples illustrate the need to understand how applications tolerate loss and latency, and to plan in QoS from the outset.

If we categorise transactions as either solicited or unsolicited, we can progress. We don't care about the response times or loss with the unsolicited transactions, unless, like many banner ads, they block, preventing valid content from being displayed until complete. For solicited transactions, like the population of a list or combo box, we must get the result in a timely manner, and so latency and loss become a consideration. These factors should strongly influence the way in which higher latency and/or lossy circuits are used in network design, including, mobile and wireless networks, cloud environments, data centre consolidations (latency due to location change and WAN versus LAN), SaaS, IaaS, PaaS, and Internet accessed applications. The modern network designer now needs to understand the nature and operation of deployed applications and the effects of infrastructure design on their performance. This is especially the case for tier 1 and other line-of-business applications that run across the network. It's more than just the volume of data.

APM measurement tools help designers to characterise applications and understand their transactional nature. In addition, Network Emulation tools can show how applications behave in new types of networks or environments such as the cloud. This understanding is vital for a smooth running network; it also de-risks network changes and new deployments. NC