Thank you so much for the hard work clarifying the many questions that you have been bombarded with over the past few days.
The python "multi-threading" support seems like good news, although I am sure many would like a little more information about the plans for python to make sure it will be the right runtime to stick with. Will the "multi-threading" in python actually be using multiprocessing to get around the GIL, similar to twisted web framework? Or will it use python's epoll, similar to the tornado web framework? Or how about a combination of both? As Dennis mentioned above, what kind of code changes may be required? Will webapp be getting a rewrite? Will frameworks such as twisted or tornado work with this new "multi-threading" python runtime? Personally, I would rather have to deal with code changes later, than to have to port my app over to java now, but as soon as this information is known by the Google App Engine team, it would be beneficial for all of us python devs to know as much as we can to plan ahead for any code changes we may have to endure later. Best On May 18, 9:49 am, stevep <[email protected]> wrote: > I have a question about structuring your on-line handlers optimally for the > new scheduler algo. > > Let's say your app handles 2 calls: > ..callA = 10ms > ..callB = 500ms > > The app averages 10 callA for every 1 callB. > > Average latency for 11 calls = 600ms / 11 calls > > That average is heavily skewed by callB. > > Will the scheduler understand this? > > Or will it be better to break the calls up into two separate handlers? > > thx, stevep -- 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.
