test management forum london – july 2010 the networked application performance lifecycle ™...

Test Management Forum London – July 2010

The Networked Application Performance Lifecycle ™ Specialists

Presented by Frank [email protected]

Satellite Networks Radio Networks Mobile NetworksWANs

The Cloud: Should We Be Worried?


Applications are being accessed differentlyApplications are being accessed differently

The Early Days

“Dumb” Terminal

• Same Building

• Short Distances

• Wired Connections

• Very Little Traffic

Mainframe



The Pre-Cloud DaysClient

• Increasingly Inter-Building

• Distances Growing

• But still mainly Wired Connections – Leased Lines & Local Area Networks

• Increasing Data Traffic over Network

Server

LAN/Leased Line

Controlled & Known

Controlled & Known

Controlled & Known



The CloudClient

• Increasingly Inter-Building

• Distances Growing

• But still mainly Wired Connections – Leased Lines & Local Area Networks

• Increasing Data Traffic over Network

Server

The “Cloud”

Controlled & Known

Controlled & Known

Uncontrolled & Unknown



Where we are today

• Increasing International-Remote Branch Offices

• Distances Growing – Inter-Continental – Latency Becoming An Issue

• Both Wired & Wireless Connections – WANs, Radio, Satellite etc

• More & More Data Traffic over Congested Networks

Application

User

Internet/WAN



• Increasing Delivery to Mobile Devices (Smart Phone/PDA/Laptops)

• Wireless Connections – Radio Networks are “Lossy”, Packets get dropped

• Restricted Throughput

Application

User

Where we are today



Where we are heading

• New Delivery Models – Cloud Computing / IaaS / SaaS / PaaS / Virtualisation / Data Centre Consolidation

• Distances Growing – Inter-Continental – Latency Becoming An Issue

• Delivered over WANs with much smaller available bandwidths than LANs

• Increasingly bandwidth-hungry applications (Video, VoIP etc. )

Application

User

Cloud Computing


Where Testing (and Development) is todayWhere Testing (and Development) is today

Typical “Lab” Software Testing Environment– Fast reliable LAN– No competing traffic– A very different environment to the WAN

So current testing techniques do not reflect the reality of how applications are being delivered today or will be in the future

Application under test

Tester or Developer

LAN


About TCP – Transmission Control Protocol

DialRing

Answer

Ring StopsHello

Hello this is…

Chat

Pause Yep/uh-huh

…etc•Transmission is guaranteed

•Lost data is resent

It’s like a phone call


About UDP – User Datagram Protocol

• It’s just like sending “text” messages• You don’t know they’ve arrived• Though you can send your own

acknowledgement UDPs (manually)– Just like texts


Choice of TCP vs UDP

• So why use UDP? Because:– the data you’re sending is not critical (a

regular status report – you’ll send another shortly)

– the data you’re sending is real time (if it was resent it would be too late)

– all that waiting for acknowledgements and retransmission takes too long

• And why use TCP? Because:– It matters that the data you sent arrives safely– It’s not real time or overly time critical


Application Protocols Using UDP

• VoIP (Voice over IP - voice only)• Live Video over IP• Streaming radio• On-line games• Telemetry


Application Protocols Using TCP

• http and https (Web access)• ftp (file transfer)• smtp (email exchange)• pop3 (email download from “post office”)• Microsoft DS (operations on file shares)• VoIP (Voice over IP - call setup only)

• Most Custom client/server applications


Both of these are affected by the Network

• Insufficient Bandwidth– UDP: cannot send – data lost– TCP: transmission slows down - resends

• Delay– UDP: too much delay and data is not “live”– TCP: transmission slows down

• Loss (Errors)– UDP: data lost – sound/picture breaks up– TCP: transmission slows down - resends


A Quick Recap on How Data is Delivered over NetworksA Quick Recap on How Data is Delivered over Networks

IP Networks break big amounts of data down into smaller data packets


TCP - Transport MechanismTCP - Transport Mechanism

Step 1• Data packets are sent in batches to their

destination

Data =

Or, using a road analogy, as a stream of cars

Data =


TCP - AcknowledgementTCP - Acknowledgement• Step 1 – Send

Send

• Step 2 – Acknowledgement - Did you get there safely?

Confirmation

• Step 3 – Send MoreSend


TCP Transport MechanismTCP Transport Mechanism


About TCP – Transmission Control ProtocolAbout TCP – Transmission Control Protocol

DialRing

Answer

Ring StopsHello

Hello this is…

Chat

Pause Yep/uh-huh

…etc•Transmission is guaranteed

•Lost data is resent

It’s like a phone call


But not all networks are the sameBut not all networks are the same

While the TCP mechanism holds constant for all networks, how the different types cope with actually delivering data can be very different because of:

– Available Bandwidth– Latency (Distance) issues– Jitter (delay variation)– Data Loss & Errors

And then there is UDP


The Different Network TypesThe Different Network Types

– “Big Pipes”– Short Distances– Low Traffic

relative to size (plenty of bandwidth)

– Basically “FAST” – Equivalent to a

3-lane motorway within your building

Local Area Networks (LANs)



– “Small Pipes”– Greater

Distances create latency issues

– High volumes of traffic relative to size (limited available bandwidth)

– Equivalent to a single track road or a 3-lane motorway with congestion

Wide Area Networks (WANs)



– “Small Pipes”– Restricted

throughput – Limited

Bandwidth– Prone to Packet

Loss

Mobile NetworksWireless Networks

Radio Networks



– “Small Pipes”– Lower

throughput – Distances

involved means latency becomes a major factor

Satellite Networks


Competing Traffic – More Delays Competing Traffic – More Delays

App 1

App 2

App 3

So, just buy more bandwidth – right?

Multiple Applications running across the network


It’s not all about bandwidth

ISPs tell you that adding more bandwidth will solve network performance problems

Latency and Packet Loss are just as important but rarely referenced…

Bandwidth


Latency or Delay

Distance = Latency– Speed of light / rules of physics apply

But Latency also caused by “obstacles”:

Routers, Switches, Repeaters…


Latency -The Problem of DistanceLatency -The Problem of Distance• The greater the distance the longer the delay• A NO-BRAINER• Result is LATENCY (or Delay)• And Wireless Suffers More than most


Delay - A Big Impact on Data Transfer TimesDelay - A Big Impact on Data Transfer Times

Test of Data Transfer Times for a 62mb file using NetBIOS – MS Share File Copy

In all Cases Using a 100 Megabit connection!


Packet Delay, Reordering & LossPacket Delay, Reordering & Loss

Ideal

5 4 3 2 1

Delay

3

Reorder

245 3 1

Loss

5 3 24 1

So, some packets never complete their journey

4 2 15


How can we test (and develop) in the “right” networks?How can we test (and develop) in the “right” networks?

Typical “Lab” Software Testing Environment– Fast reliable LAN– No competing traffic– A very different environment to the WAN, Wireless or Satellite

Network

So how can you realistically recreate the network conditions applications are likely to encounter in Non-LAN environments in order to undertake effective testing?

Application under test

Tester or Developer

LAN


Non-Options for TestingNon-Options for Testing

• Over the “lab” LAN – unrealistic• In the live production environment

– Peak times – No Way!– During “off-peak” times – not at all like during

the day• Unloaded• Superloaded with Backups etc.

• Recreate the anticipated production environment:– Create your own duplicate WAN – too expensive,

unloaded, no repeatability


Use a Network Emulator Use a Network Emulator

• A device used to recreate a complex network– High Latency WANs (National, International and Satellite)– Wireless Networks (e.g. 802.11 and 3G)– Jittery networks – such as cause VoIP deployments a problem– Networks that lose and/or damage traffic– QoS type networks, including MPLS, ATM and VLANs– It should also be possible to apply different impairments to

different traffic as would happen in a real WAN– … in a “LAB”

• Without the complex network


Create a WAN Environment in the Test LabCreate a WAN Environment in the Test Lab

Application

User

Network Emulation

Recreates:• Latency• Jitter• Insufficient Bandwidth• Packet Loss/Error/Reordering• QoS Traffic Prioritization


When to use a Network EmulatorWhen to use a Network Emulator

• Ideally throughout the Application lifecycle– When Prototyping– During Development– Functional Testing– Performance/Load Testing– Pre-deployment Testing– Post deployment testing

•Recreate current issues in the LAB


SummarySummary

To Summarise…• Applications are no longer just delivered over LANs

• Even relatively modest amounts of delay (latency), loss or errors in “Non-LAN” networks can have a big impact on application performance

• Satisfactory behaviour in LAN environments is no guarantee of acceptable behaviour in the WAN

• Testing in the live production WAN is not an option

• WAN Emulation is a good alternative

• The ability to test in WAN conditions will ensure the role of the tester remains relevant


In conclusionIn conclusion

• More info:– [email protected]– www.itrinegy.com– Youtube Videos

iTrinegy, Bulse Grange, Norton End,

Wendens Ambo, CB11 4JT, tel: 0845 226 1900

test management forum london – july 2010 the networked application performance lifecycle ™...

Documents