fteproxy

All posts by kpdyer

This post will focus on the performance and scalability of fteproxy. Specifically, we’re going to look at it’s maximal throughput in its default configuration and how it scales as the number of simultaneously connected users increases. This is, in part, motivated by the spike in fteproxy users February, which begs the question: how many fteproxy Tor bridges do we need if the number of users increase from 100s, to 1Ks, to 10Ks, etc.

TL;DR We can support at least two orders of magnitude more users with the existing infrastructure of six Tor bridges.

Our Environment

We spun up two AWS instances. Our client is an m.large instance in the US East (N. Virgina) region. Our server is an m.medium instance in he US West (Oregon) region. This asymmetry enables us to know the performance limitations of the server-side m.medium instance.

In order to establish a baseline for the performance between the two instances we use iperf. On our server we run:

$ iperf -s -p 8081

This spins up a listener on the server’s port 8081. Then on our client we run:

Iperf spins up, generates a single connection and sends as much data as possible within 10 seconds, then reports the throughput. This test reports ~160 Mbits/sec, which was a consistent result across multiple invocations of this test.

fteproxy: Single-Connection Performance

Next, we want to use iperf to test the performance of fteproxy between the client and server. We install fteproxy 0.2.19 via PyPI and then spin up the fteproxy client on our client:

$ fteproxy --mode client --server_ip $SERVER_IP

and the fteproxy server on our server:

$ fteproxy --mode server --server_ip 0.0.0.0

Then, client-side, we’re able to run iperf and connect to our local fteproxy listening port in order to tunnel iperf via fteproxy:

Single-threaded performance turns out to be exceptional. We achieve 142Mbps, compared to 160Mbps with a direct connection. This is a performance penalty of only about 12%.

fteproxy: Multiple-Connection Performance

As are final test, we use the same configuration as in the single-connection test. However, we use the “-P” switch in iperf in order to create multiple simultaneous datastreams. We performed this test for P=[10,20,…,100] and achieved the following:

A cursory analysis of the server-side side performance during these tests indicate the fteproxy is, in fact, CPU bound with 100 simultaneous users. However, this test is extreme in the sense that all connections attempted to send data as aggressively as possible. Whereas in practice a user that is, say, browsing the web using fteproxy will exhibit a less demanding workload. Hence, an fteproxy server hosted on an m3.medium instance will likely scale well beyond 100 simultaneous users.

Given that the current fteproxy usage in Tor has peaked at ~300 users/day, it appears that the fteproxy software will probably scale to serve two orders of magnitude more users with our current infrastructure of six servers.

A new testing framework has been released for fteproxy [1]. The goal of this framework is automate the process of testing fteproxy across a range of platforms and installation strategies

The testing framework validates fteproxy across 12 different platforms and two different installation strategies (via pip or via a tar/zip.) The following is a summary of the configuration used for each platform:

Debian/Ubuntu – Virtual machines were created with VirtualBox, controlled by vagrant, and shell scripts were created for each of the installation methods.

OSX – Licensing is difficult for OSX which makes it difficult to install on VirtualBox, etc. without substantial efforts. Parallels is the only VM that supports OSX as a guest — however, its scripting support is limited. Therefore, the host platform was used to do all pip tests in a virtualenv and all tar tests in a sandbox. This could be adapted to a VM in future.

Windows – VirtualBox images were created for each platform. Cygwin was installed with sshd and the default, insecure, vagrant public keys for SSH access. Vagrant boxes were then packaged, shell scripts were created to download the fteproxy zips from fteproxy.org and bat scripts were created to test the binaries.

The following table is a summary of results against fteproxy 0.2.18.

Future improvements: include testing for fteproxy’s deployment settings, such as Tor and automate the process of testing inter-version compatibility.

We are pleased to announce the release of fteproxy 0.2.7, and the initial release of fteproxy-builder 0.0.1. The purpose of this separation is to delineate between issues that are inherent to the design and engineering of fteproxy and issues that are due to building/packaging fteproxy for specific platforms.

The goal of the fteproxy-builder project is to streamline the process of building fteproxy for multiple target platforms and architectures. We are using Vagrant, VirtualBox and modern cross-compilers such that Linux, OSX, and Windows binaries of fteproxy can be built from OSX/Linux. For more details, please see the README.

The current version of fteproxy-builder supports OSX as the host platform and the binaries produced have been tested on Debian 7.1.0, Ubuntu 12.x/13.x, and Windows Vista/7/8. There is a known issues on Windows XP, which has been raised here : fteproxy-builder issue #1.

In support of fteproxy-builder, we performed a complete overhaul of the fteproxy build system. Our Makefile now supports the following options:

make – Compiles fteproxy for the host platform.

make dist – Compiles fteproxy and creates a distributable (tar.gz or zip) in the “dist” folder.

make dist-[platform]-[arch] – Performs cross-compilation and builds a package for [platform]/[arch] and places the file in the “dist” folder. Currently, only supported on Linux host machines.