2018-04-22 21:15 GMT+02:00 <nerbr...@free.fr>: > Hi, > > I created a 4MB file and rate limited its directory container in the >> httpd's conf, and tested 8/20/30/etc.. settings as you suggested with >> curl: >> >> curl http://localhost/test.txt > /dev/null (in this way I drop the >> returned response but keep the curl's connection metadata summary). >> >> In every case I get the expected result (average Dload speed). >> > > Thanks a bunch for testing this, and confirming that something is wrong on > my side. > After more test, I'm pretty sure the problem come from a bad interaction > between mod_ratelimit and mod_proxy. > (sorry, I forgot to mention that the path I was trying to rate-limit is > indeed a tomcat app behind mod_proxy). > > Did you execute your performance tests in localhost? And also, did you >> use another tool other than Firefox? I'd be curious to know your >> results with curl executed in localhost. >> > > I've tried the following (Excerpts from my config at the end of this mail): > > 0) rate-limit on tomcat app proxified throught mod_proxy (previous mail) > => rate-limit works by step, and does not limit anything if rate-limit > > 40 > (tried on local with wget) > 1) rate-limit on a true folder, served by apache : > => rate-limit is working as expected > 2) rate-limit on file served through python's SimpleHttpServer, proxified > by mod_proxy > => rate-limit works by step. > > In conclusion, tomcat is not at fault, since python's SimpleHttpServer > also have a problem, and the trouble come from my reverse-proxy. > In the case af a reverse proxy, I'm not sure which part of the connection > get rate-limited ? > Is that an known problem ? > Or am I trying to do something totally bogus here ? > Any ideas to achieve my goal ? (that is, limiting the bandwith used by the > tomcat app) > > I opened a tracking task in https://bz.apache.org/bugzilla/show_bug.cgi?id=62362, I tried to write in there an explanation about what I think it is happening.
Thanks for the report! Luca
