Load Balancer

A Load Balancer spreads incoming requests across several servers so that no single machine becomes a bottleneck, and it stops routing users to a server that has failed. For customer-facing applications, internal services or APIs, it often decides whether a traffic spike slows things down. This page helps IT managers, engineers and procurement teams choose a type, a form factor and the datasheet figures that matter.

The PonDesk listings here are PICOPC Next Generation ADC: Load Balancer Solutions. None publishes specification values in the product data available to us, so treat this page as a checklist and request each full datasheet before comparing.

Load Balancer Types: Layer 4 Versus Layer 7 Routing

Layer 4 routing chooses a backend from network-level information, such as the address and port of a connection. It never reads request content, so it handles plain TCP or UDP traffic quickly. It suits database connections or any service where every backend is interchangeable.

Layer 7 routing reads the request itself and can send traffic to different server pools by host name, URL path, header or cookie. Choose it when several applications share one address, or when an API gateway must send /images and /checkout to different clusters. Each request costs more processing, so compare requests per second, not only bandwidth.

If routing depends only on where a connection goes, layer 4 is enough. If it depends on what the user is asking for, you need layer 7.

Application Delivery Controllers and the SSL Decision

A basic load balancer distributes connections. An application delivery controller adds functions such as SSL offload, caching, request rewriting, compression and traffic policies. If one device must front several applications, look for this type, then confirm in the datasheet which functions are included and which are licensed separately.

Encryption also needs a decision. The device can terminate the session and forward clear text, or pass it through to the servers. Settle this before you size the hardware.

Deciding Whether SSL Offload Is Needed

SSL offload moves cryptographic work off the application servers and centralises certificate management, which also simplifies renewals. It helps when servers are CPU-bound or receive many short-lived encrypted connections.

If compliance requires encryption to reach the backend, you need end-to-end encryption, meaning re-encryption between the balancer and the server. Confirm that the device supports it, how much load it adds, and who can export the private keys.

Estimating TLS Transaction Load From Your Own Traffic

Measure your own peak of new encrypted connections per second, not the average, because connection setup is the expensive part. A site with many short sessions needs far more capacity than one with long-lived connections carrying large files.

Add expected growth and failover headroom. If one unit must carry the full load while its partner is down, size each unit for the full peak. Then compare your figure with the vendor's transactions-per-second value and its test conditions.

Appliance Form Factor: Hardware or Virtual

A hardware appliance is a dedicated box with predictable performance, suited to a rack with fixed capacity. The trade-offs are lead time, rack space, power and cooling, and capacity that grows in steps.

A virtual appliance runs as software on your hypervisor or cloud platform. It scales faster and suits teams that already manage virtual infrastructure. Its performance depends on the host, so ask for the recommended virtual CPU and memory, and whether shared resources affect latency at peak. Many organisations run both, so check whether one management platform covers hardware and virtual units.

Reading Capacity Figures Without Being Misled

Capacity figures are rarely comparable unless the test conditions match. Throughput is the bandwidth forwarded, measured in bits per second. Concurrent connections counts the sessions open at once. Requests and encrypted transactions per second depend on request size, encryption settings and the features enabled during the test.

Before comparing figures, check:

• Which features were enabled, such as SSL offload, layer 7 inspection or security policies. Basic forwarding inflates the numbers.
• The size of the test traffic. Small responses inflate request rates, while large files inflate throughput.
• Whether the figure covers a single unit or a high-availability pair, and whether it is a burst or a sustained rate.

Put these questions to each PICOPC Next Generation ADC: Load Balancer Solutions listing. What test profile produced each figure? Does throughput include SSL offload? How much does performance drop with health checks and logging switched on? Which figures are licensed?

Keeping Sessions Steady and Failed Servers Out of Rotation

Session persistence keeps a user on one backend for the length of a session, which matters for shopping carts, logins and any server that stores state. Health checks decide which backends are available, and failover moves traffic to a standby when the primary fails. A high-availability pair combines these functions.

Persistence can use the source address, a cookie or a request value. Source-address persistence misbehaves when many users share one corporate proxy. Cookie-based persistence is more precise but requires the application to set the cookie. Check what happens to sessions when a backend is removed.

How Health Checks Detect a Failed Backend

A health check runs against each backend at a set interval. A simple check confirms that the port accepts a connection. A stronger check requests a page or API endpoint and verifies the response, which catches a server that listens but returns errors.

Check too often and a busy server can look unhealthy. Check too rarely and users stay on a failed server for longer. Ask how many consecutive failures trigger removal, and whether sessions can drain first.

Failover Behaviour in a High-Availability Pair

In a high-availability pair, one unit is active and the other stands by, sharing configuration and connection state. Ask how fast takeover happens, whether existing connections survive, and whether persistence data reaches the standby. Losing connections at failover may suit short requests but not long uploads.

Also check how failback works after repair. Automatic failback can cause a second disruption if the repaired unit is not fully ready, so many teams prefer manual failback during business hours.

Algorithms and Deployment Modes for Your Network

Round robin suits identical servers handling requests of similar duration. Least connections suits applications where some requests run much longer than others. Weighted methods fit servers of differing capacity, and hash-based methods keep related requests together. Test the chosen algorithm under realistic load before going live.

In one-arm deployment, the balancer sits beside the traffic path on one interface, and servers need a route back to it. This is easy to add in front of existing servers. In inline deployment, the balancer sits directly in the path, giving full control, but it becomes a single point that needs high availability. When adding a balancer, move one service first and keep the old direct path available until the new one is verified.

Support Lifecycle, Firmware Cycles and Replacement Planning

A balancer usually stays in service for several years, so ask how often firmware ships, whether security fixes arrive separately from feature releases, and whether updates can be applied to one unit of a pair first. Get the end-of-sale and end-of-support dates, the cost of extended support, and whether subscriptions are tied to the hardware.

Compare total cost over the planned service life, not the purchase price alone. Schedule a replacement review before support ends, keep a tested configuration backup, and track capacity growth, since a device sized for today's peak may need replacing before its hardware fails.

See the wider Computer Systems range.

Load Balancer Supplied by PonDesk

Buying a load balancer shapes how well your applications hold up under peak traffic, so the supplier's credibility matters as much as the device. Businesses need to know the unit they receive is genuine and that the purchase process is clear.

 PonDesk, a UK-based industrial technology platform, sources its products through trusted channels and verifies them before listing, and it states that every product is genuine.

Orders can be placed online or by phone and email, with payment by PayPal, card or bank transfer, and the team offers dedicated support and technical expertise for buyers with questions before they order.