By Rick Leir, February 8, 2012
Updated February 21
The Rabbit4 web proxy can be used by an Internet Services Provider (ISP) to speed up browsing for its customers using slow links such as modems. It is also useful when the user is browsing via a satellite link, perhaps on a cruise ship. Rabbit compresses web pages, reduces image resolution, and does several other things to speed up the web. How well does it work? Let’s find out, using Apache JMeter to apply a load by simulating client browsers making requests through the proxy. JMeter also measures Rabbit’s performance in terms of response times.
The test has a few main ‘themes’:
- how many users can it support
- how well does it help a modem user
- Rabbit 4.11 binary from http://khelekore.org
- JMeter 2.6 from http://jmeter.apache.org
- Rabbit (proxy) computer: P4 HT 3.2 GHZ, 2G RAM, Fedora 16, Sun Java 6.30
- JMeter (load) computer: Core2 Quad 64 2.4 GHZ, 4G RAM, Vista, Sun Java 6.31
- Network: 1GHZ Ethernet between the load and proxy computers
- Network: 1 MHZ DSL connection from the proxy computer to the Internet
Clearly, the 1 GHZ network between the load and proxy computers is not a good simulation of modem connections. We will need to throttle that, as described below when we use Linux netem.
JMeter was configured to request URLs for 200 sites ranked most popular by Alexa (as of February 21 2012). The first 16 of them are:
- www.baidu.com – The leading Chinese language search engine
- www.qq.com – China’s largest and most used Internet service portal
- www.taobao.com – the leading consumer-to-consumer marketplace
It would be simpler to use a shorter list of sites and loop through it several times. However, since Rabbit4 caches static web content, the test would be unrealistic if it repeatedly loaded the same site. For this reason, the test loads each site once, and the Rabbit4 cache is cleared before running the test (A later test shows the benefits of Rabbit4’s cache for users when they revisit sites).
JMeter did not simulate the browser’s cache, so all web items were requested anew.
JMeter was configured with 1 Thread (user), making one sample per second. This unrealistic in that a real user might click a link once a minute or longer, depending on her habits.
A sample includes a GET for the home page of a site, and GETs for various images and scripts, so a sample comprises several HTTP requests. A GET for www.blogger.com redirects, and results immediately in a GET for www.blogger.com/home, and GETs for the images and scripts. A GET for www.live.com results immediately in a SSL CONNECT for the site.
JMeter was configured to make up to 4 concurrent connections per user, as browsers commonly do.
JMeter was configured with an HTTP cookie manager, so each thread gets its own cookies.
First, for reference, let’s do a run without Rabbit. Start JMeter so it connects directly to the Internet, not via the proxy:
The load computer is talking directly to the Internet, not via the Rabbit proxy. The Internet link is by 1Mbps DSL, Sympatico in Ottawa, with not much other traffic (only a Netflix connection at low quality). The results are:
The average response is 4.823 seconds, and median is 2.280 seconds. So pages are generally loading in about two and a half seconds.
Now let’s do a run with the proxy. Rabbit4 was run with the default configuration:
java -jar jars/rabbit4.jar -f conf/rabbit.conf
The proxy’s cache was cleared before this run. The -H and -P arguments tell JMeter where the proxy is:
$ ./jmeter -H proxyhost -P 9666
The results of the test:
The average response time is 7.569 seconds, and the median is 2.762 seconds. Some of the sites take much longer to load than others, causing a discontinuity (jump) in the plotted average.
Let’s try again, and this time Rabbit4’s cache is already loaded. Restart JMeter, but leave Rabbit4 running:
This time the average is 3.934 seconds and the median is 1.664 seconds. The cache is a big help!
(A future test): Let’s launch Rabbit4 with more VM memory:
That’s all for now! Check again soon for results with netem.