I've posted a modified version of my original post here as a blog post. Multi-threaded Python 2.7 WTFAQ? http://appenginedevelopment.blogspot.com/2011/10/multi-threaded-python-27-wtfaq.html
-- Emlyn http://my.syyn.cc - Synchonise Google+, Facebook, WordPress and Google Buzz posts, comments and all. http://point7.wordpress.com - My blog Find me on Facebook and Buzz On 15 October 2011 13:00, Emlyn <emlynore...@gmail.com> wrote: > On 15 October 2011 09:12, Ikai Lan (Google) <ika...@google.com> wrote: >> Yep, your thinking here is correct! Be careful when using global memory as a >> cache, though. Instances are capped at 128mb of memory, and if you exceed >> that, your instance will be killed. This could lead to instance thrashing. >> [On another note: congrats, you got me to read a long email ;).] >> -- >> Ikai Lan >> Developer Programs Engineer, Google App Engine >> plus.ikailan.com | twitter.com/ikai >> On Fri, Oct 14, 2011 at 2:34 AM, Emlyn <emlynore...@gmail.com> wrote: >>> >>> These are my first thoughts about approaching threaded python 2.7 >>> apps. Please critique this, I could be totally wrong here! And I don't >>> want to be wrong. Thanks in advance. >>> >>> ---- >>> >>> Hello, dummy here. >>> >>> I'm just beginning my first experiments with python 2.7 apps, using >>> "threadsafe: true". But I'm a clueless n00b as far as python goes. >>> Well, not a n00b, but still a beginner. And then this multi-threading >>> thing turns up, and I find myself groaning "oh man, really, does it >>> have to get this complex?" I think I hear a lot of similar groans out >>> there ;-) >>> >>> I'm betting that the whole "multithreaded" thing in python appengine >>> apps is scaring plenty of people. I've done a lot of concurrent >>> programming, but the prospect of dealing with threading in python has >>> daunted me a bit because I'm a beginner with python and appengine as >>> it is - this just makes life harder. But hey, it's being added for a >>> reason; I'd best quit complaining and start figuring it out! >>> >>> Thinking about threads and python, I realised that I didn't know how I >>> needed to actually use multi-threading to make my apps leaner and >>> meaner. I mean, why would I use them? They're for doing inherently >>> concurrent things. Serving up pages isn't inherently concurrent stuff, >>> at the app development level. What exactly is expected here? Shouldn't >>> the framework be doing that kind of thing for me? >>> >>> And of course that was the aha moment. The framework *is* doing the work >>> for me. >>> >>> The situation with python appengine development up until now has been >>> that instances process serially. They take a request, see it through >>> to its end. They take another request. And so on. That's cool, but >>> instances spend a lot of time sitting around waiting when they could >>> be doing more work. >>> >>> But with the new python 2.7 support, you can tell appengine that it >>> would be ok to give instances more work when they are blocked waiting >>> for something. eg: if they are doing a big url fetch, or a long query >>> from datastore, something like that, then it's cool to give them >>> another request to begin working on, and come back to the waiting >>> request later when its ready. You do that by setting "threadsafe: >>> true" in your app.yaml . >>> >>> Being threadsafe sounds scary! But actually it shouldn't be a huge >>> deal. Pretty much it's about what you shouldn't do. >>> >>> Multi-threading means having multiple points of execution on the one >>> codebase in the one address space. Anything you do to touch things >>> external to that (like datastore, memcache, url fetches) shouldn't >>> care about that (assuming the client libraries are threadsafe). And >>> normal code touching local variables will be fine. >>> >>> Probably the only real thing you've got to worry about is using >>> instance memory (global variables more or less). That's because >>> multiple requests, ie: multiple threads, can come in and fiddle with >>> that global memory at the same time. You can fix that with some >>> concurrency primitives, but if that sounds scary you can just avoid >>> touching global memory in the first place. >>> >>> So if you're using instance memory as part of a caching strategy, for >>> instance (caching like instance-memory -> memcache -> datastore), then >>> you either need to make the instance memory caching threadsafe, or >>> just stop using instance memory for that purpose. >>> >>> The other big gotcha, implied by this issue with global memory, is >>> libraries. Which libraries are threadsafe? Plenty probably aren't, >>> especially some of those shady 3rd party python libs you found lying >>> around on code.google.com . Why not? Because they use global memory. >>> But the built in libs should be ok, unless we've been specifically >>> told they're not, and I don't recall any information like that. >>> >>> Oh, and your app needs to use WSGI script handlers, presumably because >>> the cgi method we were recommended to use in py 2.5 apps is not >>> threadsafe. >>> >>> So to sum up, if you aren't too sure about multi threading and want to >>> keep it simple, it seems like you can get your existing app processing >>> parallel requests by doing the following: >>> - Remove uses of global instance memory (if you don't know what that >>> means you're probably not doing it anyway) >>> - Remove/replace non threadsafe libraries (tricky - do more >>> experienced pythonistas know of any way to easily determine this? eg >>> pre-existing lists?) >>> - Modify your app starting point, the bit that wrangles your >>> WSGIApplication, so that it works like this: >>> >>> http://code.google.com/appengine/docs/python/gettingstartedpython27/helloworld.html >>> and not like this: >>> >>> http://code.google.com/appengine/docs/python/gettingstarted/usingwebapp.html >>> - Set up your app.yaml properly, as per: >>> >>> http://code.google.com/appengine/docs/python/gettingstartedpython27/helloworld.html >>> - Update your SDK to 1.5.5 (or later) otherwise it'll refuse to upload. >>> >>> I don't think the dev appserver will run your code concurrently yet, >>> but you can always set threadsafe: false for local development, then >>> change it before you upload. >>> >>> On a related note, there is other stuff that you need to check to make >>> sure your app is ready for python 2.7, largely around newer versions >>> of libraries being used (eg: webob has changed). Check this page: >>> http://code.google.com/appengine/docs/python/python27/newin27.html >>> >>> -- >>> Emlyn >>> >>> http://my.syyn.cc - Synchonise Google+, Facebook, WordPress and Google >>> Buzz posts, >>> comments and all. >>> http://point7.wordpress.com - My blog >>> Find me on Facebook and Buzz >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Google App Engine" group. >>> To post to this group, send email to google-appengine@googlegroups.com. >>> To unsubscribe from this group, send email to >>> google-appengine+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/google-appengine?hl=en. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Google App Engine" group. >> To post to this group, send email to google-appengine@googlegroups.com. >> To unsubscribe from this group, send email to >> google-appengine+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/google-appengine?hl=en. >> > > > > -- > Emlyn > > http://my.syyn.cc - Synchonise Google+, Facebook, WordPress and Google > Buzz posts, > comments and all. > http://point7.wordpress.com - My blog > Find me on Facebook and Buzz > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
