At Fri, 7 Sep 2007 13:50:50 -0700, "Kirk Haines" <[EMAIL PROTECTED]> wrote: > > 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.
Which in my experience involves waiting for external web services, among other things. If you want to say that this is something that isn’t a typical rails app, fine. I’m telling you that my threads are often i/o bound. > 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. I understand how threads work, and I don’t think that my construction is artificial. > 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. Surely it is possible to write a C extension for Ruby that allows context switching from within it? This is outside my understanding of Ruby threads. > 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. I know why we are getting greater performance, and again, I don’t think it’s artificial. But, in any case, it was a demonstration, mostly for the original responder, who claimed that you would never get more performance from Ruby threads. Again, your mileage may vary. And it’s all moot for rails users since I don’t see rails going multithreaded. best, Erik Hetzner ;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3
pgpb5tIqgRYzG.pgp
Description: PGP signature
_______________________________________________ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
