Haven't tried that! I don't _think_ that'll work.. but worth a shot (I don't think they only cache the handler.. I think they cache the whole environment). Will report back! And as you're mentioning, we really shouldn't be doing it every request, so if there were even a way to cache that manually rather than calculate it every time, that'd be just as valuable.
There is no "zappa forum" - it's just me and a few other contributors in a Slack channel! And all of this stuff is super new, and I'm sure that you guys know a lot more about the Django internals than I do, so all suggestions are welcome! R On Tuesday, March 1, 2016 at 12:57:28 AM UTC+1, Cristiano Coelho wrote: > > Sorry if this looks like a retarded question, but have you tried the setup > calls to the top of the lambda_handler module? I'm not sure why you need > the settings data as an argument to the lambda handler, but if you find a > way to move those 4 lines near setup(), you will only load the whole django > machinery once (or until AWS decides to kill your instance). I have a wild > guess that this is related to the way you have implemented the "publish to > aws" process. But the main issue here is that you are calling setup() on > every request, where you really shouldn't be doing that, but rather do it > at module level. > > I'm sorry if this goes away too far from the actual thread, since this > looks more like a response to a zappa forum :) > > > > El lunes, 29 de febrero de 2016, 19:34:16 (UTC-3), Rich Jones escribió: >> >> For those who are still following along, these are the lines in question: >> >> >> https://github.com/Miserlou/django-zappa/blob/master/django_zappa/handler.py#L31 >> >> https://github.com/Miserlou/django-zappa/blob/master/django_zappa/handler.py#L68 >> >> It's very possible there are ways of significantly improving this. >> Suggestions always welcome! >> >> R >> >> On Monday, February 29, 2016 at 11:26:17 PM UTC+1, Rich Jones wrote: >>> >>> Hey all! >>> >>> Let me clarify a few of the terms here and describe a bit how Django >>> operates in this context. >>> >>> "Serverless" in this contexts means "without any permanent >>> infrastructure". The server is created _after_ the request comes in, and it >>> dies once the response is returned. The means that we never have to worry >>> about server operations or horizontal scalability, and we pay far, far far >>> less of a cost, as we only pay for server time by the millisecond. It's >>> also radically easier to deploy - a single 'python manage.py deploy >>> production' gives you an infinitely scalable, zero-maintenance app. >>> Basically, Zappa is what comes after Heroku. >>> >>> To do this, we use two services - Amazon Lambda and Amazon API Gateway. >>> >>> The first, AWS Lamdba - allows us to define any arbitrary function, >>> which Amazon will then cache to memory and execute in response to any AWS >>> system event (S3 uploads, Emails, SQS events, etc.) This was designed for >>> small functions, but I've been able to squeeze all of Django into it. >>> >>> The other piece, API Gateway, allows us to turn HTTP requests into AWS >>> events - in this case our Lambda context. This requires using a nasty >>> language called 'VTL', but you don't need to worry about this. >>> >>> Zappa converts this API Gateway request into a 'normal' Python WSGI >>> request, feeds it to Django, gets the response back, and performs some >>> magic on it that lets it get back out through API Gateway. >>> >>> You can see my slides about this here: >>> http://jsbin.com/movecayuba/1/edit?output >>> and a screencast here: https://www.youtube.com/watch?v=plUrbPN0xc8 >>> >>> Now, this comes with a cost, but that's the trade off. The flip side is >>> that it also means we need to call Django's 'setup()' method every time. >>> All of this currently takes about ~150ms - the majority of which is spent >>> setting up the apps. If we could do that in parallel, this would greatly >>> increase the performance of every django-zappa request. Make sense? >>> >>> >>> >>> *We also have a Slack channel <https://slackautoinviter.herokuapp.com/> >>> where we are working on this if you want to come by! *R >>> >>> -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/156e4949-d69c-4d15-9bbf-f0510902921b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
