is there any sort of inbound request limit?

February 18, 2015 2.7k views

I have tried with 3 different droplets with different linux distros installed.

it seems like there's some sort of "10req/s limit" set on its public network.

when I run apachebench or any other tools to stress test the new server, I get exactly 9~10 req/s.

it doesn't seem to be a cpu-bound or ram-bound issue since during the test, cpu utilization is kept below 1.0%

If i run the stress test in localhost, i get something like 8000req/s. hitting maximum cpu of 85~95%

here's a droplet with its current vanilla nginx settings. can you guys take a look?

http://128.199.101.235/

Is there some sort of anti-ddos limit or per-ip request limit implemented?
i've looked if there's any iptables rule or firewall(ufw) rule set on the droplet, but there weren't any.

i've tested the nginx server on port 80, 8080,21, 3389 and other ports, and same results. apache gave me same results. testing from a different remote location gave me that 10req/s limit. seems to be a server-network side issue.

4 comments
  • There is not any type of rate limiting on the network for your droplet that would cause this. Are you running behind CloudFlare or another reverse proxy service by chance? When running these benchmarks where are the requests being generated from? If possible a traceroute between that location and your droplet would be helpful in seeing if there is a network issue causing these problems for you.

  • well, it's not running behind a reverseproxy, you can test it in its pure ip-based address
    http://128.199.101.235/

    the address provided above is the vanilla droplet with no customized setting.

    so the droplet above is in "Singapore"
    also tried accessing it from another droplet in different location.

    only "a droplet in singapore" to "another droplet in singapore" configuration would give me higher than 10req/s

    any other combination gave me 10req/s

  • I know this might sound ridiculous, but can you try creating a droplet yourself, and put any http server on it and try to stress test on it using ab.exe?

    http://moonbutblack.blogspot.kr/2013/09/http-performance-testing-ab-apache.html

    because I keep asking the same question and
    I can't provide any further information if all the response I get is

    "We do not rate-limit"

    because obviously, when you try to "benchmark a droplet from another droplet"(each in different locations)

    you get similar limit.

  • :~$ traceroute 128.199.101.235
    traceroute to 128.199.101.235 (128.199.101.235), 30 hops max, 60 byte packets
    1 192.168.0.1 (192.168.0.1) 0.631 ms 1.022 ms 1.536 ms
    2 115.94.157.249 (115.94.157.249) 10.602 ms 10.732 ms 10.856 ms
    3 * * *
    4 1.213.9.141 (1.213.9.141) 11.002 ms 11.134 ms 11.251 ms
    5 1.208.8.133 (1.208.8.133) 11.423 ms 1.213.8.133 (1.213.8.133) 11.989 ms 12.134 ms
    6 203.233.17.169 (203.233.17.169) 13.814 ms 1.213.106.53 (1.213.106.53) 6.834 ms 9.242 ms
    7 210.120.103.229 (210.120.103.229) 8.567 ms 1.208.151.201 (1.208.151.201) 9.041 ms 8.941 ms
    8 1.208.148.105 (1.208.148.105) 8.720 ms 1.213.149.253 (1.213.149.253) 9.400 ms 1.213.105.21 (1.213.105.21) 11.247 ms
    9 1.208.107.34 (1.208.107.34) 11.031 ms 211.53.88.22 (211.53.88.22) 9.525 ms 1.213.104.170 (1.213.104.170) 12.071 ms
    10 203.233.35.242 (203.233.35.242) 16.054 ms 1.208.150.113 (1.208.150.113) 16.245 ms 17.071 ms
    11 TenGE0-0-0-3.br03.sin02.pccwbtn.net (63.218.228.118) 93.340 ms 92.927 ms 95.343 ms
    12 digital.ocean.te0-0-0-13.br03.sin02.pccwbtn.net (63.218.107.190) 152.788 ms TenGE0-0-0-1.br03.sin02.pccwbtn.net (63.218.228.110) 94.141 ms TenGE0-0-0-3.br03.sin02.pccwbtn.net (63.218.228.118) 96.767 ms
    13 103.253.144.234 (103.253.144.234) 159.551 ms digital.ocean.te0-0-0-13.br03.sin02.pccwbtn.net (63.218.107.190) 142.905 ms 155.176 ms
    14 103.253.144.238 (103.253.144.238) 158.512 ms 128.199.101.235 (128.199.101.235) 106.941 ms 107.662 ms

1 Answer

This question was answered by @ryanpq:

There is not any type of rate limiting on the network for your droplet that would cause this. Are you running behind CloudFlare or another reverse proxy service by chance? When running these benchmarks where are the requests being generated from? If possible a traceroute between that location and your droplet would be helpful in seeing if there is a network issue causing these problems for you.

View the original comment

Have another answer? Share your knowledge.