On 9/7/07, Erik Hetzner <[EMAIL PROTECTED]> wrote > What problem domain? Web servers in general? Web applications? Web > applications which are heavily database dependent? I show below > that there are web apps whose throughput can be improved by green > threading.
The general area of Ruby web applications and the serving thereof. > A process can use almost all the cycles available on a machine if the > scheduler allows it to, and if it has something to do. Threads and a > thread scheduler allow a process to have something to do. Sure, but the _only_ way to get this with Ruby green threads is if you have threads that are blocking on something within Ruby code, so that Ruby can context switch to a different thread and get something done with it while the first one sits around, waiting. You artificially construct exactly that scenario in your example below. I'll comment on it more in a minute. In real apps, though, most of the time, that just isn't happening. > > The work involved in handling web browser requests and rendering > > responses back to them, though, doesn't tend to fall into this > > category. It tends to be CPU intensive, and when one is waiting for > > something external, like a database query, one is usually waiting > > inside the body of the low level extension based database driver, so > > thread context switching doesn't happen there, anyway. > > In my experience web applications tend to spend most of their time > waiting for other things, from databases, web services, etc. So > obviously your mileage may vary. And when you are waiting on something like a database, you are doing it within the DB driver extension, so there are no context switches happening -- your green threads are blocked. > Below is an example of what I'm getting at. You can tweak it to test > various things. It is a simple mongrel server that sleeps for 5 usecs > and then calculates the fibonacci number of 15. You can turn it into a > multi-threaded server by commented out the synchronize stuff. On my > uniprocessor machine you get half again the performance in terms of > requests/sec from multithreaded. The reason you get more performance when multithreading is because of that sleep call. It is all happening inside of Ruby, so when running in a multithreaded context, when one thread goes to sleep, the others just get the execution cycles. It's artificial, though. Read Ruby web apps don't tend to have latencies like that. When they are waiting, they are waiting inside of things that block the entire Ruby process, and not just waiting for something that is blocking a single thread. Kirk Haines _______________________________________________ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
