apache – John Leach

Rate limiting with Apache and mod-security

Rate limiting by request in Apache isn’t easy, but I finally figured out a satisfactory way of doing it using the mod-security Apache module. We’re using it at Brightbox to prevent buggy scripts rinsing our metadata service. In particular, we needed th e ability to allow a high burst of initial requests, as that’s our normal usage pattern. So here’s how to do it.

Install mod-security (on Debian/Ubuntu, just install the libapache2-modsecurity package) and configure it in your virtual host definition like this:

SecRuleEngine On

<LocationMatch "^/somepath">
  SecAction initcol:ip=%{REMOTE_ADDR},pass,nolog
  SecAction "phase:5,deprecatevar:ip.somepathcounter=1/1,pass,nolog"
  SecRule IP:SOMEPATHCOUNTER "@gt 60" "phase:2,pause:300,deny,status:509,setenv:RATELIMITED,skip:1,nolog"
  SecAction "phase:2,pass,setvar:ip.somepathcounter=+1,nolog"
  Header always set Retry-After "10" env=RATELIMITED
</LocationMatch>

ErrorDocument 509 "Rate Limit Exceeded"

(more…)

15/5/2012 15 Comments

Rubinius multiple instances, one process

Rubinius has support (as of today!) for running multiple instances of it’s VM within one process, each VM on it’s own *native* thread, each VM running many ruby green threads. Each VM has it’s own heap and so each VM could load different apps that wouldn’t interfere with each other. We have plans for a mod_rubinius for apache that takes full advantage of this feature. Stay tuned ;)

– Ezra Zygmuntowi on a comment on Ruby Inside.

Very interesting stuff. Why bother making Rails thread safe when you have an awesome Ruby VM such as Rubinius. I’d like to see Mongrel (or FastCGI! Bring back FastCGI!) make use of this somehow, running multiple Rails instances itself in one process and distributing requests between them. Interested in knowing how it’d deal with memory leaks in external libraries though (like rmagick suffers from).

Still, you lose finer grained access to most of the nice UNIX process management stuff though then, like limiting memory usage with ulimits, but nobody seems to be using that for Ruby deployment anyway. It’s all fiddling around with Monit and such instead (why always with the steps backward!).

15/1/2008 Add Comment

Turck MMCache speediness on Debian Sarge

UPDATE: The info in this post is deprecated. See the new post about eAccelerator instead.

I installed Turck MMCache PHP accelerator and I got a big improvement.

ApacheBench reported 4.52 pages per second before and 12.47 pages after installation (a WordPress 1.5.2 page on a 1.2Ghz PIII). That a 275% increase in performance, with currently no observed problems. I tested this with both Apache2 and lighttpd, and got a similar boost with both.

There is only a package for Debian unstable at the moment, so I downloaded the package source and backported it to Debian sarge. I put the package in my apt repository (along with a backported openswan package I’m using). Add to your sources.list:

deb http://johnleach.co.uk/downloads/debian sarge backports

and apt-get update ; apt-get install turck-mmcache

See PHP fly (comparatively)

UPDATE: I’m running into a few problems now actually. WordPress runs fine, but an application of my own is having some serious problems. MMTurck is kicking out the following log message:

[13072] MMCACHE: PHP crashed on opline 1 of main() at /path/to/webapp/cligs-app.php:24

I’ve disabled the extension for now until I investigate further.

UPDATE: S

12/1/2006 1 Comment