Performance is inferior to Firefox's nsITraceableChannel

[rpelizzi]

I am developing a Firefox addon which rewrites incoming traffic using nsITraceableChannel, and I tried to decouple it from Firefox and put the logic into a separate HTTP proxy using this package. I knew doing MITM with HTTPS would use a little more resources due to SSL/gzip decoding/encoding, but the proxy is much slower, to the point that I can't even use it for testing. And it doesn't even seem like the proxy is hitting the CPU too hard, it's just slow! Is the slower performance normal, or do I definitely have some sort of bug that severely degrades performance? I am caching requests with the following helper function, based on the examples in tests/:

ctx.cacheAndModify = function(f) {
  var data = "";
  ctx.onResponseData(function(ctx, chunk, cb) {
    data += chunk.toString();
    return cb(null, null);
  });
  ctx.onResponseEnd(function(ctx, cb) {
    var opts = ctx.proxyToServerRequestOptions;
    var url = (ctx.isSSL ? "https" : "http") + "://" + opts.host +
      (opts.port === 443 || opts.port === 80 ? "" : ":" + opts.port) +
      opts.path;
    ctx.proxyToClientResponse.write(new Buffer(f(data, url)));
    return cb();
  });
};

so then I can just use ctx.cacheAndModify(handler) in onResponse. I also use Proxy.gunzip

[felicienfrancois]

Well, there could be a lot of reasons for performance drawbacks.
I don't think gunzip is the most significant, as the response from server is decoded but not reencoded, so it just move the decode step from the browser side to the proxy side.

SSL can be time consuming, especially on first request on a domain, as we have to generate a different SSL certificate for each domain. Then there is SSL decryption/encryption and SSL negociation/handshake that could takes time.
Also, by design, http-mitm-proxy opens a new https server on a random port for each domain. Opening a new server should not takes too much time, except if there is some security checks by the OS or an antivirus software.
This could probably be improved by either using local sockets instead of ports or even better by handling the request dirrectly without using a http/https server.

Then, there may also be perf issues due to NodeJS, which is single threaded, especially on heavy load (may not be an issue for a browser extension).

Also, http-mitm-proxy does not supports SPDY nor HTTP/2 yet, so you can have notifiable performance downgrade on website that supports thoose technologies.
Supports for thoose tech could be added, even if current NodeJS implementations of HTTP/2 are not stable and have performance issues.

I think the best thing to do before going further in implementation is a performance benchmark to identify what are the biggest perf issues.
This could be done on both sides:

• On the browser side, by recording request timings (SSL negotiation, connecting, waiting, and receiving), on several cases, with and without the proxy.
• On the proxy side, by adding timestamped logs everywhere