On Sun, Sep 11, 2011 at 6:31 PM, Steve <[email protected]> wrote: > > On my GET requests, I/O accounts for roughly half of the time to process the > request. When a user POSTs new data, my app does a fair amount of > recalculations and I/O is only about 20% of the request processing time. So > 50% of my GETs and 80% of my POSTs would benefit from the improved > concurrency of the new GIL.
Ok, you have one of those odd cpu-bound apps. If multithreaded concurrency is hardcoded to a fixed number then yeah, the GIL hurts you. I don't know what the plans are for Python, but in Javaland, Google has said that the initial limit of 10 is temporary and concurrency will be determined by CPU usage. Assuming G follows through on scheduling by CPU usage (maybe they already have), then the GIL still doesn't matter. Each instance will take requests until it maxes out X amount of CPU, then you'll start a new instance. Basically, the GIL doesn't hurt anymore than single-threading hurts Node.js systems. As long as you don't block for I/O, you will serve to the best ability of CPU resources. The GIL is just like green threads back in the early days of the JVM. Actually, I would be surprised of green threads don't start making a comeback with modern multicore architectures. Jeff -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
