Acquire does seem rather drastic, but I can see how it might result in the desired behavior.

As for mod_proxy’s documentation, it is not as clear as I like but I would not describe the verbage around max as unclear. Specifically, it says, “Apache will never create more than the Hard Maximum connections to the backend server.” That could easily be wrong but is hardly unclear.

I fought with this a few months ago, and I concluded that… this “max” parameter…. how do you say… “I do not think it means what you think it means.” :)

The mod_proxy documentation could certainly be clearer, but my reading is that the setting is always per Apache child process. So, in a typical prefork setup with, oh I don’t know, 10 or 15 apache processes, you really end up with a max of 10 or 15 connections per Mongrel. (And when you get busy and Apache spins up more children, you get even more connections per Mongrel.) Basically you still end up with the “dumb” round-robin allocation. Not what you or I intended.

With the worker MPM, you can lock down ServerLimit so that everything is in lots of threads within one process, but that seems risky and probably not great at high load. But with worker, you at least have some control.

Here’s a mailing list post touching on this:
http://marc.info/?l=apache-httpd-dev&m=112552197217868

However, refusing to believe that Apache is completely incapable of being a proper Rails frontend (as you said, nothing “fancy” is needed, just a dispatcher that finds or waits for an idle backend), I persisted in my googling.

I ended up finding a reference to the “acquire” parameter… probably this message: http://rubyforge.org/pipermail/mongrel-users/2007-October/004146.html

The Apache docs for “acquire” (a parameter to ProxyPass, like “max”) make it sound pretty drastic. True, if all backends are busy for the duration of the acquire timeout, it’ll return a 503 Server Busy, but if any backends are idle it appears to make Apache hunt for one (after the timeout) instead of just picking a possibly busy one and waiting.

For us, “acquire=1″ has worked out pretty well. We also have “max=1″ but because of the above I don’t think it’s actually doing anything. Just make sure you have enough Mongrels. (Easy to say of course. :))

HAproxy is still probably a better bet. Rather pathetic that Apache is too “dumb/smart” to front for Mongrel/Rails isn’t it? Maybe someday someone will hack on Apache to make it behave properly in front of Rails. Or maybe we’ll all end up using mod_rails or whatever they’re calling it these days. :)

Keep me posted.
Casey

That does not appear to be exactly what I want. I don’t want requests dispatched to the least busy backend. I want them dispatched to a not busy backend. If there is not an idle backend available, I want them queued until there is one.

Consider following scenario:

time       1     2     3     4     5
======================================
backends
  1        |-----------------| (a)
                     |........-----| (c)

  2              |-----| (b)

A fair balancer without a connection limit might (correctly) send request c to backend 1. This is because all the backends are equally “busy” it is not wrong to send that request to any backend. However, as human you can see that it ends up have quite suboptimal results in this scenario

Basically any balancer algorithm with the ability to set a max connections on each backend (that actually worked) would solve my problem. Once there is a balancer for nginx that has that I am there.

Nginx is a fantastic (and lightweight) reverse proxy and the Upstream fair load balancer loads your back end processes according to usage.

The module is here.

http://github.com/gnosek/nginx-upstream-fair/tree/master

Glenn