Multiple load-balanced instances
You may want to run two or more instances of SwiperProxy for various reasons. This can be on the same machine, or on multiple machines.
Of course, you could simply refer a portion of your users to proxy1 and the other part to proxy2. However, more advanced techniques allow you to automate this process and distribute traffic between your instances.
Using load balancing software
Just like how you can use a webserver to reverse proxy to a single SwiperProxy instance, it is also possible to reverse proxy to multiple instances. The method to do this greatly differs between webservers, and it's recommended you view your webserver documentation on how to do this.
An alternate method of load balancing, which does not necessarily require a dedicated software or hardware node, is called round robin DNS. In this technique, multiple IP addresses are associated with a single domain name; clients are expected to choose which server to connect to. Unlike the use of a dedicated load balancer, this technique exposes to clients the existence of multiple backend servers. The technique has other advantages and disadvantages, depending on the degree of control over the DNS server and the granularity of load balancing desired.
Another more effective technique for load-balancing using DNS is to delegate proxy.example.org as a sub-domain whose zone is served by each of the same servers that are serving the web site. This technique works particularly well where individual servers are spread geographically on the Internet. For example:
backend1.example.org A 192.0.2.1 backend2.example.org A 203.0.113.2 proxy.example.org NS backend1.example.org proxy.example.org NS backend1.example.org
However, the zone file for proxy.example.org on each server is different such that each server resolves its own IP address as the A-record. On backend one the zone file for proxy.example.org reports:
@ in a 192.0.2.1
On backend two the same zone file contains:
@ in a 203.0.113.2
This way, when a server is down, its DNS will not respond and the web service does not receive any traffic. If the line to one server is congested, the unreliability of DNS ensures less HTTP traffic reaches that server. Furthermore, the quickest DNS response to the resolver is nearly always the one from the network's closest server, ensuring geo-sensitive load-balancing. A short TTL on the A-record helps to ensure traffic is quickly diverted when a server goes down. Consideration must be given the possibility that this technique may cause individual clients to switch between individual servers in mid-session.
Using the rewrite function
The proxy.conf configuration allows URL rewriting. You can use this to rewrite traffic from one proxy to the other. While very limited, this could be used to have one proxy with a restrictive whitelist but high bandwidth to access certain sites, and rewrite all other destinations to the secondary proxy - implementing a QoS-esque mechanic.