0

Is there any sort of rate limiting on the RPC-HTTP API? Trying to track down why my node (private chain) can only handle ~40 requests per/second. I am only load testing it with eth_blockNumber so they are quick calls. But after around 1200-1600 requests it starts to give ECONNREFUSED errors.

My go-ethereum node is hosted on an AWS EC2 instance (not behind a ELB), but for the load testing I'm testing directly with the instance's IP:port. I've tested a local node with the same load test and it passes fine, but not sure if this is a good 1-1 test since its just hitting localhost.

Wondering if its AWS rate limiting? But from what I have read they don't have that built-in, only if you use an Elastic Load Balancer. And I wouldn't think 40 requests per second would make it think it's a DDOS attack.

Any help is appreciated!

1

My hunch is you're probably doing async requests that open up new connections for each call.

From my own experience with running a GETH node, i can tell you that yes, the limit is internal and working as expected, if you're opening up new connections for each request then you're going to end up with what you're experiencing. The geth logs should tell you that you've reached the limit.

My solution to the issue was to setup a proxy nginx server that just handles the "connections" and forwards them to the Geth node.

This works because nginx will keep the connection alive and just forward requests to the node. This way every piece of software does what's intended to do :)

i.e.

    location /geth.ropsten {
            proxy_pass "http://192.168.0.15:8545/";
    }

    location /geth.ropsten.ws {
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Origin '';
            proxy_set_header Connection "Upgrade";
            proxy_pass "http://192.168.0.15:8546/";
    }

    location /parity.ropsten {
            proxy_pass "http://192.168.0.16:8545/";
    }

    location /parity.ropsten.ws {
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Origin '';
            proxy_set_header Connection "Upgrade";
            proxy_pass "http://192.168.0.16:8546/";
    }

With this you could even setup a load balancer proxy ( like infura does ), and propagate requests between multiple nodes in order to scale.

  • 1
    Thanks for the reply @MickySocaci. Actually I am also running the node behind an Nginx reverse proxy as well. My config looks exactly the same as yours. I've tried to whitelist a specific IP for disabling rate limiting, but didn't work for me. Guess I will try and revisit this route. Thanks for the input! Oh, quick question, is your domain routed via a CDN (Cloudflare)? Mine is and I'm thinking I should remove that and just hit the server directly. – The Nomad Jul 8 at 6:32
  • 1
    My domain is hosted on my own dev machine with nothing in front, so that could be the case why it works versus yours, feel free to try it out nowlive.ro/geth.ropsten / nowlive.ro/parity.ropsten also just as a test check out nowlive.ro/zoom - github.com/MCROEngineering/zoom if you're ever wondering about batching a ton of calls into One :) – Micky Socaci Jul 8 at 6:46
  • 1
    Regarding cloudflare, you probably want to whitelist your source ip and try to call the "real ip" of that instance, just to make sure it's not CF the one that's rate limiting you. Just make sure you're hitting nginx and not geth directly. – Micky Socaci Jul 8 at 6:47
  • Sounds good, will take a look. Thanks for the sources! – The Nomad Jul 8 at 7:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.