Application performance can be viewed differently by users and administrators. For users, performance means quick response and usability, while administrators focus on efficient network resource usage. Performance is also dependent on application type, with bulk file transfers prioritizing bandwidth over round-trip time compared to transactional applications. Key metrics for measuring performance include round-trip time, goodput, protocol overhead, and bandwidth-delay product. Transactional applications are more sensitive to round-trip time while streaming applications depend more on bandwidth-delay product. Environmental factors like network bandwidth and latency also significantly impact performance.

1. Network Characteristics of Cloud Architecture1

2. Performance Dimensions
2
¨ Application performance differs according to perspective.
¤ For a user, an ideal application would deliver high performance
and responsiveness.
¤ For an administrator, an ideal application would consume the
least amount of network resources.
¨ Performance also differs based on application type.
¤ Performance for a bulk file transfer application might have
different implications than performance for a transactional
application.

3. Stakeholders: Users and Administrators
¨ Users want applications to be fast
and predictable.
¨ Users judge application performance
by their experience:
¤ Is the application quick to respond?
¤ Is an hourglass icon/pinwheel
displayed while background
operations are carried out?
¤ Does the application launch and close
quickly?
¤ Are errors handled in an
understandable way?
¨ Administrators want applications to scale.
¨ Administrators often judge an
application's performance on how
efficiently it uses network resources.
¨ Administrators may ask:
¤ Does the application have low overhead
and efficient network usage?
¤ Are the minimum number of connections
used, so my server can service as many
users at once as possible?
¤ Am I constantly calling helpdesk?
3

4. Measuring application performance
4
¨ Round Trip Time (RTT)
¤ Time for a request to make a trip from a source to a destination and back
¤ Factors affecting RTT:
n Network infrastructure, distance between nodes, network conditions, and packet size,
congestion payload compressibility, forward error correction and data compression
¨ Goodput
¤ Measure of useful application data successfully processed by the receiver, in
bits-per-second.
n Enables the measurement of effective or useful throughput and includes only
application data
n Packet, protocol, and media headers are considered overhead, and are not part of
goodput

5. Measuring application performance
5
¨ Protocol Overhead
¤ Non-application bytes (protocol and media framing) divided by the total
number of bytes transmitted (expressed as percent).
¨ Bandwidth-Delay Product
¤ Bits-per-second bandwidth of the network X the RTT (in seconds)
¤ # of bits it takes to fill available network bandwidth
¤ When the value for bandwidth-delay product is high, the TCP/IP stack must
handle large amounts of unacknowledged data in order to keep the pipeline full
¤ A key end-to-end metric for streaming applications

6. Network Characteristics of Cloud Apps
6
¨ Network/protocol characteristics of cloud apps
depend broadly on the app type
¨ Transactional versus Streaming Apps
¤ Transactional apps are also called interactive
¤ Streaming apps are also referred to as batch
processing applications

7. Environmental Factors
7
¨ Application that perform fine on a
local computer may cause significant
performance degradation/resource
consumption when run across a
network
¨ Environment affects application
performance
¤ Transactional applications are more
sensitive to RTT
¤ Streaming applications are more sensitive
to bandwidth-delay product
LAN
Dial up Satellite / WAN
Internet and
VPN
LOW HIGH
LOW
HIGH
Bandwidth
RTT

8. Transactional versus Streaming Apps
¨ Transactional applications
¤ Stop-and-go
¤ Perform request/reply
operations
n Data is ordered (often)
¤ Examples
n synchronous remote
procedure call (RPC)
n some HTTP and (DNS)
implementations
¨ Streaming applications
¤ Move data
¤ Pedal-to-the-metal data
transmission philosophy
n Less concern for data
ordering
¤ Examples
n network backup
n file transfer protocol (FTP)
8

9. Avoidable Behaviors
9
¨ Chatty Applications
¤ Some applications perform many small transactions. When combined with the network overhead
associated with each such transaction, the effect is multiplied. In networking, small transactions can
consume as many resources and as much time as large transactions. A better approach is to combine
many small transactions into a single large transaction.
¨ Serialized Transactions
¤ Unnecessary serialization of transactions can result in poor performance, and affect scalability. For
example, 1000 serialized transactions take at least 1000 * RTT to complete. A better approach is to
run unrelated transactions in parallel
¨ Fat Transactions
¤ Applications that send unnecessary bytes on the network are considered fat applications. Applications
that send unnecessary bytes on the network increase network overhead, and performance is hampered.
This situation often comes from inefficient data structures or inefficient data streaming. To remedy this,
optimize data structures, or consider using compression

10. Questions and discussion on topic
10

11. 11
Thank you.