5 ms·

one mongrel handles one request. if you request takes one second to complete. you get one request/sec. 7 mongrels => 7 req/sec. 100req/sec * 7 mongrels => 7

by socmoth 19y ago

one mongrel handles one request. if you request takes one second to complete. you get one request/sec. 7 mongrels => 7 req/sec. 100req/sec * 7 mongrels => 700 req/sec total. and other simple math. they aren't spawned automatically. you setup a number and distribute to them. there are ways of getting them to spawn automatically, but it isn't inherent to mongrel itself.

mrtron 19y ago
Oh, I see, thanks. So I now ask, why have not spawn them automatically?
- sbraford 19y ago
  That's a really good question, eh? :) It seems to me the webserver would then need to support that (dynamic allocation of additional target mongrels). The way it works currently is you put Apache2 / Lighty / nginx / etc in front, working as a proxy, which has a list of host/port pairs which it forwards on the request to. The proxying end of things would have to be smart enough to tell mongrel to startup more processes, and begin forwarding more requests to those.
  - davidw 19y ago
    Whereas, with something like Rivet or Websh (or PHP for that matter, even if I don't like the language), it's good old tried and true Apache taking care of dynamically allocating new servers as needs be... fancy that! I love Rails, but those guys are too anxious to throw the Apache baby out with the PHP bathwater.
    - sbraford 19y ago
      I agree, being forced to know ahead of time how many mongrels you'll need is sub-optimal. At the same time, it's trivial to switch this number if you've not hit your server resource limits yet. (i.e. when coming under a digg load) Once server limits are reached (in Apache or nginx/mongrel/rails), the point is moot - you'll have to instantiate new servers at your co-lo / hosting company by hand anyway. All that said, nginx is a fantastic web & proxy server. It blows Apache out of the water in terms of memory usage, etc.
      - davidw 19y ago
        nginx - isn't it just another in a long line of select-based web servers that "blow Apache out of the water" when it comes to serving static resources? boa was what I set up to serve static files at Linuxcare back in ... 1999? Or is nginx different somehow? That's fine as far as it goes, but the tricky part lies in serving up the dynamic stuff.
        carpal 19y ago
        Nginx is both incredibly fast at serving static files and pretty useful all around for reverse proxies and whatnot (not to mention being easier to configure/maintain than apache). I use it at work and it has been fantastic.
        altano 19y ago
        It's not select based, it is event based, utilizing the relatively new support for event-driven IO in the Linux and FreeBSD kernels (kqueue/epoll).
        davidw 19y ago
        Ok, so it's a slightly different architecture, but it's still really an evolution of the single-process select-based server. To do anything "application like" - running code in ruby, php, python - you apparently (correct me if I'm wrong, because I'm just going from what I found after 5 minutes on the site) have to farm things out to FCGI, so you're back to the Apache model of separate processes - noting of course that unlike some people erroneously think, apache's processes each have a select loop, so it's not just forking processes for every connection! My point is that the application processes are where things are tricky. Even 'big slow apache' can saturate fast connections with static content. The real trick is to get the most out of your dynamic code without under utilizing your resources (by launching only one mongrel instance, for example), or running things into the ground by letting your apps try and grab too much memory.
- socmoth 19y ago
  i just noticed replies. mongrel doesn't do it for the same reason tar doesn't support encryption (pgp does!). mongrel is designed to serve requests, not balance requests or spawn itself. sure it could, but it doesn't have to. it is just as easy to have another project spawn more mongrels. That way if I want to to write software just for looking at my servers and making more mongrels, i can, very easily. Otherwise i have to look in mongrel's code.

by socmoth 19y ago

mrtron 19y ago

Oh, I see, thanks. So I now ask, why have not spawn them automatically?

sbraford 19y ago
That's a really good question, eh? :) It seems to me the webserver would then need to support that (dynamic allocation of additional target mongrels). The way it works currently is you put Apache2 / Lighty / nginx / etc in front, working as a proxy, which has a list of host/port pairs which it forwards on the request to. The proxying end of things would have to be smart enough to tell mongrel to startup more processes, and begin forwarding more requests to those.
- davidw 19y ago
  Whereas, with something like Rivet or Websh (or PHP for that matter, even if I don't like the language), it's good old tried and true Apache taking care of dynamically allocating new servers as needs be... fancy that! I love Rails, but those guys are too anxious to throw the Apache baby out with the PHP bathwater.
  - sbraford 19y ago
    I agree, being forced to know ahead of time how many mongrels you'll need is sub-optimal. At the same time, it's trivial to switch this number if you've not hit your server resource limits yet. (i.e. when coming under a digg load) Once server limits are reached (in Apache or nginx/mongrel/rails), the point is moot - you'll have to instantiate new servers at your co-lo / hosting company by hand anyway. All that said, nginx is a fantastic web & proxy server. It blows Apache out of the water in terms of memory usage, etc.
    - davidw 19y ago
      nginx - isn't it just another in a long line of select-based web servers that "blow Apache out of the water" when it comes to serving static resources? boa was what I set up to serve static files at Linuxcare back in ... 1999? Or is nginx different somehow? That's fine as far as it goes, but the tricky part lies in serving up the dynamic stuff.
      - carpal 19y ago
        Nginx is both incredibly fast at serving static files and pretty useful all around for reverse proxies and whatnot (not to mention being easier to configure/maintain than apache). I use it at work and it has been fantastic.
      - altano 19y ago
        It's not select based, it is event based, utilizing the relatively new support for event-driven IO in the Linux and FreeBSD kernels (kqueue/epoll).
        davidw 19y ago
        Ok, so it's a slightly different architecture, but it's still really an evolution of the single-process select-based server. To do anything "application like" - running code in ruby, php, python - you apparently (correct me if I'm wrong, because I'm just going from what I found after 5 minutes on the site) have to farm things out to FCGI, so you're back to the Apache model of separate processes - noting of course that unlike some people erroneously think, apache's processes each have a select loop, so it's not just forking processes for every connection! My point is that the application processes are where things are tricky. Even 'big slow apache' can saturate fast connections with static content. The real trick is to get the most out of your dynamic code without under utilizing your resources (by launching only one mongrel instance, for example), or running things into the ground by letting your apps try and grab too much memory.
socmoth 19y ago
i just noticed replies. mongrel doesn't do it for the same reason tar doesn't support encryption (pgp does!). mongrel is designed to serve requests, not balance requests or spawn itself. sure it could, but it doesn't have to. it is just as easy to have another project spawn more mongrels. That way if I want to to write software just for looking at my servers and making more mongrels, i can, very easily. Otherwise i have to look in mongrel's code.