Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Slow Responses #314

Open
ZacS803 opened this Issue · 12 comments

8 participants

@ZacS803

Hi,

I am having some issues with node-http-proxy. I am running node 0.8.10 on Linux (Debian Squeeze).

Without routing through node-http-proxy I see response times of 16 - 30ms. With I get 200+ms.

What am I doing wrong?

The code I have tried is below:

var http = require('http');
var httpProxy = require('http-proxy');

//HTTP Proxy Example

//
// Create an instance of node-http-proxy
//
var proxy = new httpProxy.HttpProxy({
  target: {
    host: '10.0.15.155',
    port: 80
  }
});

var server = http.createServer(function (req, res) {
  //
  // Proxy normal HTTP requests
  //
  proxy.proxyRequest(req, res);
});

server.listen(8081);

//Routing Proxy Example
var proxy = new httpProxy.RoutingProxy();

var server = http.createServer(function(request, response) {
                                proxy.proxyRequest(request, response, {host:'10.0.15.155',port:80});
                                });

server.listen(80);

Regards,
Zac

@robertlmullen74

Hey Zac,
I was seeing some similar issues to and posted an issue on it, no response yet, but it turns out the dns lookup was the bottleneck. I posted most of my notes with the issue.
#305
Rob

@ZacS803

Hi Rob,

I am not 100% sure if mine is the same issue, as I am proxying direct to an IP, so there shouldn't be a DNS lookup?

Did you find any workarounds or fixes to your issue?

Cheers,
Zac

@robertlmullen74

We haven't done anything yet, still testing out other options, but we're thinking of mapping the dns to IP's and doing lookups based on that, which for us has proven to be fast.

@mmalecki

Could you profile it and find where it spends its time? We're using it in production with under 20 ms of round trip.

@frizinak

Same issue, with http-proxy : 200ms+ and without 5-20ms.
http listening on localhost:8080, proxy on localhost:80. (doing a simple res.write('hi') & res.end())

don't know if it can help: v8 profiling
http://pastebin.com/Qv3NZC1b

@frizinak

timestamp:
1355848457504 PROXY REQUEST - createServer callback
1355848457543 RENDERED - httpserver (8080) receives request 39ms later
1355848457547 SENT - http server has called response.end()
1355848457557 PROXIED - proxyserver.proxy.on('end')
chrome : blocking 0ms, sending: 0-1ms waiting: 200-270ms, receiving: 0-2ms (dns lookup if not cached: 0ms)
1355848875418 RENDERED
1355848875419 SENT
chrome : blocking 0ms, sending: 0-1ms waiting: 5-7ms, receiving: 0-2ms

Hope this helps in any way, will be looking at the source later tonight trying to find the slowest callback in http-proxy
(note: I'm just starting out with nodejs so I might be doing something retarded, but as I've created numerous new projects with base httpserver + http-proxy, I'm pretty sure it's either http-proxy or my ubuntu server box )

edit: ran same script on windows box, no issues (with or without proxy 5-15ms round trip).
Back on linux I tried changing the port from 80 to >8000, (no sudo) same issue persists.
Tried with bouncy, same issue. Gonna look into that, will update when I find it (It obviously doesn't seem to be a bug in http-proxy).

@indexzero
Owner

I suspect it is not http-proxy. I heard some noise about spurrious latency from the DNS lookup in node.js core since lookups are not cached.

@frizinak

Yeah it's not a bug in http-proxy, couldn't find any other info on the issue though.
To me it seems it can't be DNS lookup (or atleast in my case) cause all the servers are hosted on 1 box, referencing eachother through 127.0.0.1:port.

Funny thing is the only 3 people reporting this issue are running debian based OS's

If this isn't the right place to discuss this any further I'll post a link to stackoverflow or something.

edit: wrote a simple http proxy, 2 http server, first one creates a client and connects to second -> 260ms ubuntu, 10ms windows.
Tried bouncy again, thought it reproduced this issue but apparently it doesn't (20-30ms). Gonna have a look at that (Not using bouncy cause it causes other issues (stops sending chunks after 64kb etc))

@clayzermk1

I believe I am also experiencing this issue.

I am using Debian 6.0.6 x86_64 and using the local /etc/hosts file to do my DNS resolution (no DNS server available).
I have tried using both IPs and hostnames in the routes of http-proxy with the same results.
GET requests are failing randomly with a Status of "(failed)" and a Type of "Pending" but a Time that seems perfectly reasonable (6ms-60ms ish).
I too think it is odd that the only ones experiencing this issue are running a Debian-based OS.

Has anyone made any further progress on this?

@download13

I'm using Fedora 13 and it's happening to me as well. Why is it even doing a DNS lookup for IP addresses? Is Node using the OS libraries to parse IP addresses? If they are only doing a parse and not a lookup there really shouldn't be a delay anyway. Am I missing something?

@robertlmullen74

There's no DNS lookup happening for IP addresses, checkout this gist I wrote to help illustrate the difference between DNS vs IP resolution. https://gist.github.com/robertlmullen74/3834431

The DNS lookup was buried somewhere deep in the node.js C core libraries, I forget exactly how it's being done, but I do recall seeing that the result was never cached.

@alekmych alekmych referenced this issue in observing/balancerbattle
Closed

http-proxy under Debian based distr #6

@unusualbob

Also seeing this on Ubuntu.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.