What Is Performance Testing: Guide to Speed, Scalability and Reliability

Users don’t wait. If a page stalls, a checkout hangs, or a dashboard times out, people leave and systems buckle under the load. Performance testing is how teams get ahead of those moments. It measures how fast and stable your software is under realistic and extreme conditions. Done right, it gives you hard numbers on speed, scalability, and reliability, and a repeatable way to keep them healthy as you ship new features.

Problem:

Modern applications are a web of APIs, databases, caches, third-party services, and front-end code running across networks you don’t fully control. That complexity creates risk:

• Unpredictable load: Traffic comes in waves—marketing campaigns, product launches, or seasonal surges create sudden spikes.
• Hidden bottlenecks: A single slow SQL query, an undersized thread pool, or an overzealous cache eviction can throttle the entire system.
• Cloud cost surprises: “Autoscale will save us” often becomes “autoscale saved us expensively.” Without performance data, cost scales as fast as traffic.
• Regressions: A small code change can raise response times by 20% or increase error rates at high concurrency.
• Inconsistent user experience: Good performance at 50 users says nothing about performance at 5,000 concurrent sessions.

Consider this real-world style example: an ecommerce site that normally handles 200 requests per second (RPS) runs a sale. Marketing expects 1,500 RPS. The team scales web servers but forgets the database connection pool limit and leaves an aggressive retry policy in the API gateway. At peak, retries amplify load, connections saturate, queue times climb, and customers see timeouts. Converting that moment into revenue required knowledge of where the limits are, how the system scales, and what fails first—exactly what performance testing reveals.

Possible methods:

Common types of performance testing

Each test type answers a different question. You’ll likely use several.

• Load testing — Question: “Can we meet expected traffic?” Simulate normal and peak workloads to validate response times, error rates, and resource usage. Example: model 1,500 RPS with typical user think time and product mix.
• Stress testing — Question: “What breaks first and how?” Push beyond expected limits to find failure modes and graceful degradation behavior. Example: ramp RPS until p99 latency exceeds 2 seconds or error rate hits 5%.
• Spike testing — Question: “Can we absorb sudden surges?” Jump from 100 to 1,000 RPS in under a minute and observe autoscaling, caches, and connection pools.
• Soak (endurance) testing — Question: “Does performance degrade over time?” Maintain realistic load for hours or days to catch memory leaks, resource exhaustion, and time-based failures (cron jobs, log rotation, backups).
• Scalability testing — Question: “How does performance change as we add resources?” Double pods/instances and measure throughput/latency. Helps validate horizontal and vertical scaling strategies.
• Capacity testing — Question: “What is our safe maximum?” Determine the traffic level that meets service objectives with headroom. Be specific: “Up to 1,800 RPS with p95 < 350 ms and error rate < 1%.”
• Volume testing — Question: “What happens when data size grows?” Test with large datasets (millions of rows, large indexes, deep queues) because scale often changes query plans, cache hit rates, and memory pressure.
• Component and micro-benchmarking — Question: “Is a single function or service fast?” Useful for hotspot isolation (e.g., templating engine, serializer, or a specific SQL statement).

Key metrics and how to read them

Meaningful performance results focus on user-perceived speed and error-free throughput, not just averages.

• Latency — Time from request to response. Track percentiles: p50 (median), p95, p99. Averages hide pain; p99 reflects worst real user experiences.
• Throughput — Requests per second (RPS) or transactions per second (TPS). Combine with concurrency and latency to understand capacity.
• Error rate — Non-2xx/OK responses, timeouts, or application-level failures. Include upstream/downstream errors (e.g., 502/503/504).
• Apdex (Application Performance Index) — A simple score based on a target threshold (T) where satisfied ≤ T, tolerating ≤ 4T, and frustrated > 4T.
• Resource utilization — CPU, memory, disk I/O, network, database connections, thread pools. Saturation indicates bottlenecks.
• Queue times — Time waiting for a worker/thread connection. Growing queues without increased throughput are a red flag.
• Garbage collection (GC) behavior — For managed runtimes (JVM, .NET): long stop-the-world pauses increase tail latency.
• Cache behavior — Hit rate and eviction patterns. Cold cache vs warm cache significantly affects results; measure both.
• Open vs closed workload models — Closed: fixed users with think time. Open: requests arrive at a set rate regardless of in-flight work. Real traffic is closer to open, and it exposes queueing effects earlier.

Example: If p95 latency climbs from 250 ms to 900 ms while CPU remains at 45% but DB connections hit the limit, you’ve likely found a pool bottleneck or slow queries blocking connections—not a CPU bound issue.

Test data and workload modeling

Good performance tests mirror reality. The fastest way to get wrong answers is to test the wrong workload.

• User journeys — Map end-to-end flows: browsing, searching, adding to cart, and checkout. Assign realistic ratios (e.g., 60% browse, 30% search, 10% checkout).
• Think time and pacing — Human behavior includes pauses. Without think time, concurrency is overstated and results skew pessimistic. But when modeling APIs, an open model with arrival rates may be more accurate.
• Data variability — Use different products, users, and query parameters to avoid cache-only results. Include cold start behavior and cache warm-up phases.
• Seasonality and peaks — Include known peaks (e.g., Monday 9 a.m. login surge) and cross-time-zone effects.
• Third-party dependencies — Stub or virtualize external services, but also test with them enabled to capture latency and rate limits. Be careful not to violate partner SLAs during tests.
• Production-like datasets — Copy structure and scale, not necessarily raw PII. Use synthetic data at similar volume, index sizes, and cardinality.

Environments and tools

Perfect fidelity to production is rare, but you can get close.

• Environment parity — Mirror instance types, autoscaling rules, network paths, and feature flags. If you can’t match scale, match per-node limits and extrapolate.
• Isolation — Run tests in a dedicated environment to avoid cross-traffic. Otherwise, you’ll chase phantom bottlenecks or throttle real users.
• Generating load — Popular open-source tools include JMeter, Gatling, k6, Locust, and Artillery. Managed/cloud options and enterprise tools exist if you need orchestration at scale.
• Observability — Pair every test with metrics, logs, and traces. APM and distributed tracing (e.g., OpenTelemetry) help pinpoint slow spans, N+1 queries, and dependency latencies.
• Network realism — Use realistic client locations and latencies if user geography matters. Cloud-based load generators can help simulate this.

Common bottlenecks and anti-patterns

• N+1 queries — Repeated small queries per item instead of a single batched query.
• Chatty APIs — Multiple calls for a single page render; combine or cache.
• Unbounded concurrency — Unlimited goroutines/threads/futures compete for shared resources; implement backpressure.
• Small connection pools — DB or HTTP pools that cap throughput; tune cautiously and measure saturation.
• Hot locks — Contended mutexes or synchronized blocks serialize parallel work.
• GC thrashing — Excess allocations causing frequent or long garbage collection pauses.
• Missing indexes or inefficient queries — Full table scans, poor selectivity, or stale statistics at scale.
• Overly aggressive retries/timeouts — Retries can amplify incidents; add jitter and circuit breakers.
• Cache stampede — Many clients rebuilding the same item after expiration; use request coalescing or staggered TTLs.

Best solution:

The best approach is practical and repeatable. It aligns tests with business goals, automates what you can, and feeds results back into engineering and operational decisions. Use this workflow.

1) Define measurable goals and guardrails

• Translate business needs into Service Level Objectives (SLOs): “p95 API latency ≤ 300 ms and error rate < 1% at 1,500 RPS.”
• Set performance budgets per feature: “Adding recommendations can cost up to 50 ms p95 on product pages.”
• Identify must-haves vs nice-to-haves and define pass/fail criteria per test.

2) Model realistic workloads

• Pick user journeys and arrival rates that mirror production.
• Include think time, data variability, cold/warm cache phases, and third-party latency.
• Document assumptions so results are reproducible and explainable.

3) Choose tools and instrumentation

• Pick one primary load tool your team can maintain (e.g., JMeter, Gatling, k6, Locust, or Artillery).
• Ensure full observability: application metrics, infrastructure metrics, logs, and distributed traces. Enable span attributes that tie latency to query IDs, endpoints, or user segments.

4) Prepare a production-like environment

• Replicate instance sizes, autoscaling policies, connection pool settings, and feature flags. Never test only “dev-sized” nodes if production uses larger instances.
• Populate synthetic data at production scale. Warm caches when needed, then also test cold-start behavior.

5) Start with a baseline test

• Run a moderate load (e.g., 30–50% of expected peak) to validate test scripts, data, TLS handshakes, and observability.
• Record baseline p50/p95/p99 latency, throughput ceilings, and resource usage as your “known good” reference.

6) Execute load, then stress, then soak

• Load test up to expected peak. Verify you meet SLOs with healthy headroom.
• Stress test past peak. Identify the first point of failure and the failure mode (timeouts, throttling, 500s, resource saturation).
• Soak test at realistic peak for hours to uncover leaks, drift, and periodic jobs that cause spikes.
• Spike test to ensure the system recovers quickly and autoscaling policies are effective.

7) Analyze results with a bottleneck-first mindset

• Correlate latency percentiles with resource saturation and queue lengths. Tail latency matters more than averages.
• Use traces to locate slow spans (DB queries, external calls). Evaluate N+1 patterns and serialization overhead.
• Check connection/thread pool saturation, slow GC cycles, and lock contention. Increase limits only when justified by evidence.

8) Optimize, then re-test

• Quick wins: add missing indexes, adjust query plans, tune timeouts/retries, increase key connection pool sizes, and cache expensive calls.
• Structural fixes: batch operations, reduce chattiness, implement backpressure, introduce circuit breakers, and precompute hot data.
• Re-run the same tests with identical parameters to validate improvements and prevent “moving goalposts.”

9) Automate and guard your pipeline

• Include a fast performance smoke test in CI for critical endpoints with strict budgets.
• Run heavier tests on a schedule or before major releases. Gate merges when budgets are exceeded.
• Track trends across builds; watch for slow creep in p95/p99 latency.

10) Operate with feedback loops

• Monitor in production with dashboards aligned to your test metrics. Alert on SLO burn rates.
• Use canary releases and feature flags to limit blast radius while you observe real-world performance.
• Feed production incidents back into test scenarios. If a cache stampede happened once, codify it in your spike test.

Practical example: Planning for an ecommerce sale

Goal: Maintain p95 ≤ 350 ms and error rate < 1% at 1,500 RPS; scale to 2,000 RPS with graceful degradation (return cached recommendations if backend is slow).

1. Workload: 60% browsing, 30% search, 10% checkout; open model arrival rate. Include think time for browse flows and omit it for backend APIs.
2. Baseline: At 800 RPS, p95 = 240 ms, p99 = 480 ms, error rate = 0.2%. CPU 55%, DB connections 70% used, cache hit rate 90%.
3. Load to 1,500 RPS: p95 rises to 320 ms, p99 to 700 ms, errors 0.8%. DB connection pool hits 95% and queue time increases on checkout.
4. Stress to 2,200 RPS: p95 600 ms, p99 1.8 s, errors 3%. Traces show checkout queries with sequential scans. Connection pool saturation triggers retries at the gateway, amplifying load.
5. Fixes: Add index to orders (user_id, created_at), increase DB pool from 100 to 150 with queueing, add jittered retries with caps, enable cached recommendations fallback.
6. Re-test: At 1,500 RPS, p95 = 280 ms, p99 = 520 ms, errors 0.4%. At 2,000 RPS, p95 = 340 ms, p99 = 900 ms, errors 0.9% with occasional fallbacks—meets objectives.
7. Soak: 6-hour run at 1,500 RPS reveals memory creep in the search service. Heap dump points to a cache not honoring TTL. Fix and validate with another soak.

Interpreting results: a quick triage guide

• High latency, low CPU: Likely I/O bound—database, network calls, or lock contention. Check connection pools and slow queries first.
• High CPU, increasing tail latency: CPU bound or GC overhead. Optimize allocations, reduce serialization, or scale up/out.
• Flat throughput, rising queue times: A hard limit (thread pool, DB pool, rate limit). Increase capacity or add backpressure.
• High error rate during spikes: Timeouts and retries compounding. Tune retry policies, implement circuit breakers, and fast-fail when upstreams are degraded.

Optimization tactics that pay off

• Focus on p95/p99: Tail latency hurts user experience. Optimize hot paths and reduce variance.
• Batch and cache: Batch N small calls into one; cache idempotent results with coherent invalidation.
• Control concurrency: Limit in-flight work with semaphores; apply backpressure when queues grow.
• Right-size connection/thread pools: Measure saturation and queueing. Bigger isn’t always better; you can overwhelm the DB.
• Reduce payloads: Compress and trim large JSON; paginate heavy lists.
• Tune GC and memory: Reduce allocations; choose GC settings aligned to your latency targets.

Governance without red tape

• Publish SLOs for key services and pages. Keep them visible on team dashboards.
• Define performance budgets for new features and enforce them in code review and CI.
• Keep a living playbook of bottlenecks found, fixes applied, and lessons learned. Reuse scenarios across teams.

Common mistakes to avoid

• Testing the wrong workload: A neat, unrealistic script is worse than none. Base models on production logs when possible.
• Chasing averages: Median looks fine while p99 burns. Always report percentiles.
• Ignoring dependencies: If third-party latency defines your SLO, model it.
• One-and-done testing: Performance is a regression risk. Automate and re-run on every significant change.
• Assuming autoscaling solves everything: It helps capacity, not necessarily tail latency or noisy neighbors. Measure and tune.

Quick checklist

• Clear goals and SLOs defined
• Realistic workloads with proper data variance
• Baseline, load, stress, spike, and soak tests planned
• Full observability: metrics, logs, traces
• Bottlenecks identified and fixed iteratively
• Automation in CI with performance budgets
• Production monitoring aligned to test metrics

In short, performance testing isn’t a one-off gate—it’s a continuous practice that blends measurement, modeling, and engineering judgment. With clear objectives, realistic scenarios, and disciplined analysis, you’ll not only keep your app fast under pressure—you’ll understand precisely why it’s fast, how far it can scale, and what it costs to stay that way.

Some books about performance:

These are Amazon affiliate links, so I make a small percentage if you buy the book. Thanks.

• Systems Performance (Addison-Wesley Professional Computing Series) (Buy from Amazon, #ad)
• Software Performance Testing: Concepts, Design, and Analysis (Buy from Amazon, #ad)
• The Art of Application Performance Testing: From Strategy to Tools (Buy from Amazon, #ad)

Overview on Performance Testing

What is Performance Testing?

What are secret-key and public-key signatures?

- Asymmetric cryptography is often referred to as the public-key cryptography. 

- It is a cryptographic algorithm which makes use of two individual keys namely the secret key and the public key. 

- The secret is kept private and the public key is open. 

- Even though these two keys are different, there is some mathematical link between the two. 

- The key which is used for the encryption of the plain text and verification of the digital signature is the public key. 

- So, the private key is one that is used for the decryption of the cipher text in to plain text or for creation of a digital signature. 

- Both these keys are contrast of each other unlike in the symmetric cryptography where the same key serves both the purposes. 

- The public keys are created based up on some mathematical problems for which presently there is no efficient solution such as the following:

Ø  Elliptic curve relationships

Ø  Discrete logarithms

Ø  Integer factorization

- Generating the public and the private key pair is computationally easy for the users. 

- The strength of the public keys lies in the fact that determining the private key from its public key is computationally in feasible or almost impossible. 

- Thus, without fearing any compromise with the security, the public key can be published whereas the private key is kept hidden from everyone so as not to reveal it to anyone who does not has authorization for performing the digital signatures or reading the messages. 

- Unlike for the symmetric key algorithms, a secure initial exchange of the secret keys is not required for the public key algorithms. 

- In the process of message authentication, a private key is used for processing a message for producing the digital signature. 

- After doing so, the signature can be verified by anyone by processing the value of the signature using the corresponding public key of the signer. 

- The result is then compared with the message. 

- The unmodified nature of the message is confirmed a success signal. 

- Also, it is presumed that the private key of the signer has been kept hidden from the others. 

- However, in practical applications, the message’s digest or hash is encrypted and used as the signature. 

- The fundamental security components of the cryptosystems, protocols and applications are the public key algorithms.

These systems underpin the following internet standards:

Ø  PGP

Ø  GPG

Ø  TLS or transport layer security

- Secrecy as well as Key distribution is provided by some of the public key algorithms such as the Diffie-Hellman key exchange algorithm while some algorithms like Digital signature algorithm provide the digital signature and some others offer both the things.

- An example of such algorithm is RSA. 

- All these algorithms have been widely accepted. 

- A pair of cryptographic keys (i.e., a public key for encryption and a private key for decryption) is provided to each of the users. 

- Similarly, for digital signatures the pair of keys consists of a private key for signing and a public key for verification. 

- The concept of the private key has been introduced so as to ensure the confidentiality. 

- The digital signatures can be verified by anyone possessing the corresponding public key. 

- With such a confirmation it is confirmed the private key is possessed by the sender. 

- This is also a way to confirm that no tampering has been done to the message. 

- If the message has been tampered, it will introduce changes in the encoded message digest. 

- Mail box having a mail slot and a personal wax seal can be taken as an analogy to public – key encryption and digital signatures respectively. 

What is meant by multiplexing?

- Multiplexing or muxing is a very important process in computer networks and the telecommunications. 

Using this process, a number of digital data streams or analog message signals are combined as one signal and then transported over the common medium. 

- Multiplexing is used wherever it is required to share a resource that is very expensive. 

- The most common example of multiplexing is of using one wire for several telephone calls. 

- The origin of the multiplexing dates back to 1870s when telegraphy was started.

- Now it is used to a great extent in the field of communications. 

- The telephone carrier multiplexing was developed by George Owen Squire in the field of telephony. 

- The communication channel over which the multiplexed signal might be transmitted might be a physical transmission medium. 

- The high level communication channel’s capacity is divided by multiplexing process in to a number of low level logical channels where for each message or data stream one channel is used. 

- Demultiplexing is the reverse process of multiplexing. 

- This is used for the extraction of the original signals on the reception side.

- A multiplexer or MUX is a device that is used for carrying out the multiplexing process and the demultiplexer or DEMUX is the device that performs demultiplexing. 

- IMUX or inverse multiplexing is another process whose aim is just the opposite of the multiplexing.

- It breaks down a single data stream in to various streams while transferring them at the same time over various communication channels.

- Later, the original stream is recreated.

Types of Multiplexing

Many different types of multiplexing technologies are available today. Each has its own significance:

Ø SDM or space-division multiplexing: 

This technique implies on using different point – to – point wires for individual communication channels. For example, an audio cable of analogue stereo, multi – pair telephone cable, switched star network, mesh network. However typically the wired SDM is not usually considered as multiplexing. In SDM a phased array antenna is formed by multiple antennas. For example MIMO (multiple – input and multiple – output), SIMO (simple – input and multiple – output), MISO (multiple – input and single – output) etc.

Ø  FDM or frequency-division multiplexing: 

This is considered to be an analog process, here the signals are sent in to different frequency ranges over a shared medium. For example, TV and radio broadcasting from satellite stations through the earth’s atmosphere. One cable is given in each house but over this cable many signals can be sent to other subscribers also. For accessing the desired signal, the users require to tune to that particular frequency. WDM or wavelength division multiplexing is a variant of FDM.

Ø TDM or time-division multiplexing: 

Unlike FDM, TDM is a digital technology but very rarely it might be used as an analog technology also. The process involves putting bytes in a sequence for each input stream one by one. this sequencing is done in such a way that the receiver can appropriately  receive them. If this is done quickly, the fact that another logical communication path was served in that circuit time won’t be detected by the receiver.

Ø  CDM or code-division multiplexing: 

In this multiplexing technique, the same frequency spectrum is shared by the several channels at the same time. Also the bandwidth of the spectrum is quite high when compared to the symbol rate or the bit rate. It is implemented in either of the two forms namely direct sequence spread spectrum and frequency hopping.

Some other types of multiplexing techniques which are less prominent are:

Polarization-division multiplexing: Used in optical and radio communications.

Orbital angular momentum multiplexing

Differentiate between transparent and nontransparent fragmentation?

A number of problems are encountered because of the size of the data packets. There is no ability in the data link layer by means of which it could handle these problems and so the bridges also don’t work here. 

The Ethernet also experiences a number of problems because of the following:

Ø  Different way in which the maximum packet size is defined.

Ø  Maximum packet size that can be handled by a router.

Ø  The maximum length slot that are used for transmission

Ø  Errors due to the packet length

Ø  Standards

The data packets can be fragmented in two ways namely:

1. Transparent and
2. Non – transparent

Both these ways can be followed based on a network by network basis. We can also say that no such end – to – end agreement exists based up on which it can be decided which process is to be used.

Transparent Fragmentation: 

- This type of fragmentation is followed when a packet is split in to smaller fragments by a router.

- These fragments are sent to the next router which does just the opposite i.e., it reassembles the fragments and combine them to form original packet. 

- Here, the next network does not come to know whether any fragmentation has taken place. 

- Transparency is maintained between the small packet networks when compared to the other subsequent networks.

- For example, transparent fragmentation is used by the ATM networks by means of some special hardware. 

- There are some issues with this type of fragmentation. 

- It puts some burden on the performance of the network since all the fragments have to be transmitted through the same gateway. 

- Also, sometimes the repeated fragmentation and reassembling has to be done for small packet network in series. 

- Whenever an over-sized packet reaches a router, it is broken up in to small fragments. 

- These fragments are transported to the next exit router. 

- The fragments are assembled by this exit router which then forwards them to the next router.

- Awareness regarding this fragmentation is not maintained for the subsequent networks. 

- For a single packet fragmentation is done many times before the destination is finally reached. 

- This of course consumes a lot of time because the repeated fragmentation and assembling has to be carried out. 

- Sometimes, it also presents the reason of corrupting the packet’s integrity.

Non-Transparent Fragmentation: 

- In this type, the packet is split in to fragments by one router. 

- But the difference is that these fragments are not reassembled until the fragments reach their destination. 

- They remain split till then. 

- Since in this type of fragmentation the fragments are assembled only at the destination host, the fragments can be routed independent of each other. 

- This type of fragmentation also experiences some problems such as header has to be carried by each of the fragments till they reach their destination. 

- Numbering has to be done for all the fragments so that no problem is experienced in reconstructing the data stream.

Whichever type of fragmentation we use, one thing has to be made sure which is that later we should be able to form the original packets using the fragments. This insists on having some type of labeling for the fragments. 

Segmentation is another name for the fragmentation. A packet is injected in to the data link layer by the IP layer but it is not responsible for reliable transmission of the packets. Some maximum value on the size of the packets is imposed by each layer for their reasons. For a large packet that travels through the network for which the MTU is small, fragmentation is very much needed. 

What is inter-network routing?

In this article we shall discuss about inter-network routing. Before moving to that there are certain terms with which you should be familiar:

Ø  End systems: The ISO (the international standards of organization) defines the end systems as the network elements that do not have the ability of forwarding the packets across the networks. Sometimes the term host is used to refer to the end systems.

Ø  Intermediate systems: These are the network elements that have the ability of forwarding the packets across the network. Most common examples are routers, switches, bridges and so on.

Ø  Network: It can be defined as a part of the inter-network infrastructure encompassing various elements including hubs, repeaters, bridges and so on. The networks are bounded by the intermediate systems.

Ø Router: This is one of the intermediate systems that is used for connecting various networks with each other. It might support one protocol (router) or many protocols (multi-protocol router). Its hardware part is optimized especially for performing routing. The software part is responsible for carrying out the routing and takes care of the routing tables.

Apart from these devices, there are 3 types of addresses involved in inter-network routing:

Ø  The inter-network address: The host address and the network address are combined together to form this address. This is used for unique identification of a host over the inter-network.

Ø The host address or host ID: This ID might be assigned by the administrator or might be simply the physical address of the host. It is used for the unique identification of the host on its network.

Ø  The network address or network ID: This is address of a network for identifying it in an inter-network.

All the data packets consist of a network layer header. This network layer header consists of the following when the packet is transmitted from one host to another:

ØThe address of the source inter-network: This address combines the address of the source host and the source network.

ØThe address of the destination inter-network: This address combines the address of the destination host and the destination network.

ØThe hop count: This usually begins at zero and is numerically incremented when the packet crosses a router. Or in the opposite case it might be assigned some maximum value which might be decremented on reaching a router. The purpose of using the hop count is to make sure that the packet does not keeps on circulating endlessly in the network.

- For inter-network routing, two things have to be known.

- Firstly, how do you reach other routers which lie in the same network and secondly, how do you reach other routers which lie in other networks? 

- The answer to the first question is easy as it is the common routing problem among two hosts residing over the same network. 

- This routing is handled by the interior gateway protocol and it is different for different networks since only local routing info is required. 

- In this case, the commonly used protocol is the open shortest path first or OSPF protocol. 

- The routing between two different networks is performed using the exterior gateway protocol. 

- This is actually the problem of inter-network routing. 

- Here, the commonly used protocol is the BGP or the border gateway protocol. 

- The graph for inter-network routing is quite different from the one that is used in the network routing. 

- This is so because the routers which lie in the same network can be thought of as being directly connected to one another for routing across inter-network. - All the networks in an inter-network function as though they are one large unit. 

What are general principles of congestion control?

- Problems such as the loss of data packets occur if the buffer of the routers overflows.

- This overflow is caused by the problem of the congestive collapse which is a consequence of the network congestion. 

- If the packets have to be re-transmitted more than once, it is an indication that the network is facing the problem of congestion. 

- Re-transmission of the packets is the treatment of only this indication but not for problem of the network congestion. 

- In the problem of congestive collapse, there are a number of sources that make attempts for sending data and that too at a quite high rate. 

- For preventing this problem of the network congestion, it requires mechanisms that are capable of throttling the sending node if in case the problem of network congestion occurs. 

- Network congestion is a real bad thing as it manifests in the network’s performance that the upper layer applications receive. 

- There are various approaches available for preventing and avoiding the problem of network congestion and thus implementing proper congestion control. 

- When the capacity of the network is exceeded by the demands for the resources and too much queuing occurs in the network causing loss of packets, congestion of packets is said to occur. 

- During this problem of network congestion, the throughput of the network might drop down to zero and there might be a high rise in the path delay. 

- Network can recover from the state of congestive collapse using a congestion control scheme. 

- A network can operate in a region where there is high throughput but low delay with the help of the congestion avoidance scheme.

- These schemes keep the network away from falling in to a state of congestive collapse. 

- There is a big confusion over congestion control and congestion avoidance. Most of us think it is the same thing but it is not. 

- Congestion control provides a recovery mechanism whereas the congestion avoidance provides a prevention mechanism. 

- Today’s technological advances in the field of networking have led to a rise in the network links’ bandwidth. 

- In the year of 1970, ARPAnet came in to existence and built using the leased telephone lines that had a 50 kbits/second bandwidth. 

- LAN (local area network) was first developed in the year of 1980 using token rings and Ethernet and offered a bandwidth of 10 mbits/ second. 

- During the same time many efforts were made for standardizing the LAN using the optical fibers providing a 100 mbits/seconds and higher bandwidth. 

- Attention to the congestion control has been increased because of the increase in the mismatching that occurs between the various links composing the network. 

- Routers, IMPs, gateways, intermediate nodes links etc. are the hot-spots for the congestion problems. 

- It is at these spots that the bandwidth of the receiver falls short for accommodating all the incoming traffic. 

- In the networks using the connection-less protocols, it is even more difficult to cope with the problems of network congestion. 

- It is comparatively easy in the networks using the connection-oriented protocols.

- This happens so because in such networks, the network resources are kept under advance reserve during setting up the connection.

- One way for controlling congestion problems is preventing the setting up of new connections if congestion is detected anywhere in the network but it will also prevent the usage of the reserved resources which is a disadvantage. 

What is the difference between congestion control and flow control?

Flow control and congestion control are similar sounding concepts and often confuse us sometimes. In this article we shall discuss about the differences between these two. 

- Computer networks use the flow control mechanism for keeping control over the data flow between two nodes in such a way that the receiver if it is slower when compared to the sender is not outrun by it. 

- The mechanism of flow control also provides ways to the receiver to maintain control over the speed with which it transmits the information.

- On the other side, the congestion control provides mechanism for the controlling the data flow under the condition of actual congestive collapse. 

- The mechanism keeps a control over the entry of data in to the network so that this traffic can be handled by the network effectively.  

- The mechanism of flow control does not let the receiving node get overwhelmed by the traffic that is being sent by another node. 

There are several reasons why this flow of data gets out of control and affects the network negatively. 

- First reason being that the receiving node might not be capable of processing the incoming data as fast as it is being sent by the sender node. 

- Based on these reasons there are various types of flow control mechanisms available. 

- However, the most common categorization is based on the fact whether the feedback is being sent to the sender or not. 

- There is another flow control mechanism called the open loop flow control mechanism. 

- In this mechanism no feedback is sent to the sender by the receiver and this perhaps the most widely used flow control mechanism. 

- Opposite of open loop flow control mechanism is the closed loop flow control. 

- In this mechanism, the receiver sends back congestion information to the sender. 

- Other commonly used flow control mechanisms are:

Ø  Network congestion

Ø  Windowing flow control

Ø  Data buffer etc.

- Congestion control offers such methods that can be used for regulating the incoming traffic in the network to such an extent where the network itself can manage all that.
- In congestion control, the network is prevented from falling in to a state of congestive collapse. 
- In such a state either little or no communication happens.
- This little communication is of no help. 
- Switching networks usually require congestion control measures than any other type of networks. 
- The congestion control is driven by the goal of keeping the number of data packets at such a level that the performance of the network would be reduced dramatically.
- Congestion control mechanism can be seen even in protocols such as UDP (user datagram protocol), TCP (transport control protocol) and other transport layer protocols. 
- TCP makes use of the exponential back off and slow start algorithms. 
- We classify the congestion control algorithms based up on the feedback that is given by the network, the performance aspect that has to be improved, and modifications that have to be made for the present network, fairness criterion that is being used and so on. 

- Congestion and flow control are two very important mechanisms used for keeping the traffic flow in order. 
- Flow control is a mechanism that stretches from one end to another i.e., between the sender and the receiver where the speed of sender is much higher than that of the receiving node. 
- Congestion control is implemented for preventing packet loss as well as delay that is caused as a side effect of the network congestion. 
- Congestion is meant for controlling the traffic of the entire whereas flow control is limited to transmission between two nodes.

How can the problem of congestion be controlled?

Networks often get trapped in the situation of what we call network congestion. For avoiding such collapses, congestion avoidance and congestion control techniques are often used by the networks nowadays. 

In this article, we discuss about how we can control the problem of network congestion using these techniques. Few very common techniques are:

1. Exponential back off (used in CSMA/ CA protocols and Ethernet.)
2. Window reduction (used in TCP)
3. Fair queuing (used in devices such as routers)
4. The implementation of the priority schemes is another way of avoiding the negative effects of this very common problem. Priority schemes let the network transmit the packets having higher priority over the others. This way only the effects of the network congestion can be alleviated for some important transmissions. Priority schemes alone cannot solve this problem.
5. Another method is the explicit allocation of the resources of the network to certain flows. This is commonly used in CFTXOPs (contention – free transmission opportunities) providing very high speed for LAN (local area networks) over the coaxial cables and phone lines that already exist.

- The main cause of the problem of network congestion is the limited capacity of the network. 

- This is to say that the network has limited. 

- The resources also include the link throughput and the router processing time. 

- Congestion control is concerned with curbing the entry of the traffic in to the telecommunications network so that the problem of congestive collapse can be avoided. 

- The over-subscription of the link capabilities is avoided and steps are taken to reduce the resources. 

- One such step is reducing the packet transmission rate. 

- Even though if it sounds similar to flow control, it is not the same thing. 

- Frank Kelly is known as the pioneer of the theory of congestion control. 

- For describing the way in which the network wide rate allocation can be optimized by the individuals by controlling their rates, he used two theories namely the convex optimization theory and the micro economics theory. 

Some optimal rate allocation methods are:

Ø  Max – min fair allocation

Ø  Kelly’s proportional fair allocation

Ways to Classify Congestion Control Algorithm

There are 4 major ways for classifying the congestion control algorithms:

1. Amount as well as type of feedback: This classification involves judging the algorithm on the basis of multi-bit or single bit explicit signals, delay, loss and so on.
2. The performance aspect taken for improvement: Includes variable rate links, short flow advantage, fairness, links that can cause loss etc.
3. Incremental deployability: Modification is the need of sender only, modification is required by receiver and the sender, modification is needed only by the router, and modification is required by all three i.e., the sender, receiver and the router.
4. Fairness criterion being used: It includes minimum potential delay, max – min, proportional and so on.

Two major components are required for preventing network congestive collapse:

1. End to end flow control mechanism: This mechanism has been designed such that it can respond well to the congestive collapse and thus behave accordingly.
2. Mechanism in routers: This mechanism is used for dropping or reordering packets under the condition of overload.

- For repeating the dropped information correct behavior of the end point is required. 

- This indeed slows down the information transmission rate. 

- If all the end points exhibit this kind of behavior, the congestion would be lifted from the network. 

- Also, all the end points would be able to share the available bandwidth fairly. - Slow start is another strategy using which it can be ensured that the router is not overwhelmed by the new connections before congestion can be detected.