support pypy

[lanterndev]

pypy could result in significant performance improvements for a pure python version of fteproxy (#104), possibly for the current version too? cffi can be used with both pypy and cpython to interface with any required c or c++ libraries too. any interest in investigating, or already on your radar?

[kpdyer]

The main performance bottleneck for fteproxy has historically been multiple-precision arithmetic in our core algorithms. I doubt that pypy would be able to outperform a well-written implementation in GMP/gmpy. At the moment, our fte.cDFA module (C++) holds all the performance critical code and is fast. However, I'm interested in suggests on how to improve it further.

I wasn't aware of cffi --- I'll check it out.

In regards to the other parts of the code, it would be interesting to find ways to further improve the current implementation, such as the network and buffering logic. I'm also interested in establishing a test framework that would allow us to benchmark fteproxy under heavy load and lots of clients. This would allow us to decide what is actually a meaningful performance improvement.

I just tried to compile fte.cDFA with pypy and it failed. I'll keep this open until that issue is resolved.

[oxtoacart]

@kpdyer I put together some benchmarking stuff for LittleProxy based around JMeter. Basically, I serve up a mirror of a somewhat large Wikipedia page from a local server and then have multiple clients access that page concurrently (including fetching all associated resources like JavaScript, CSS and media). JMeter resembles a real-world browser in this regard, and this test is a decent way to get a feel for a proxy's overhead.

[kpdyer]

@oxtoacart Very interesting. Does that benchmark give you a feeling for how many simultaneous clients LittleProxy can handle?

[oxtoacart]

The benchmark was really designed to test overhead on a client performing "realistic" workloads rather than server-side concurrency. For testing concurrency, the current setup has some limitations:

1. I should really serve the content from a separate server than the test machine
2. AFAIK, JMeter uses threading with blocking I/O, so it's unlikely to be able to achieve a level of concurrency that would stress LittleProxy (which uses non-blocking I/O). For testing concurrency, something like wrk would be a great option if it only supported proxies. I'm tempted to enhance boom to support running against a proxy, which shouldn't be too hard.

[oxtoacart]

Oh, and I should probably just serve up the content with Nginx or something like that instead of Jetty.

[oxtoacart]

Here's a fork of boom that can talk to proxies - https://github.com/oxtoacart/boom/

It's been pull requested.