Sane defaults for Startapp and Startproject

[Rich Jones]

Hey guys!

So I've just written a blog post about getting started with Django,
http://gun.io/blog/python-for-the-web/, and many of the things here
just make me think, 'why doesn't it just do that by default?'

Here's some of what I propose. I'm not suggesting this be a canonical
list of features by any means, I'm just suggesting that django have
more convenient default settings. We should look at the most common
conventions and best practices and shape the defaults towards them.

Anyway, I propose that:

django-admin.py startproject newproj

should create ./static, ./uploads and ./newproj and ./newproj/
templates

in ./newproj/settings.py..

import os
TEMPLATE_DIRS = (
os.path.join(os.path.dirname(__file__), 'templates'),
)

and at the end, the commonly used from local settings import * block.

I'd also suggest that django-admin.py startproject newapp, if
possible, add the new application to the settings.py file if it can be
done so safely.

I would also suggest that when making a new application, the most
commonly used imports are already there in the py files
(render_to_response, HttpResonse, get_object_or_404, etc).

Who's with me? :)

R

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Sane defaults for Startapp and Startproject

[Rich Jones]

How would you guys feel about a manage.py startexample

which would create an example application? A simple, templated hello
world with an example model and an example view and an example
template?

R

On Oct 20, 4:50 pm, Aymeric Augustin
 wrote:
> On 20 oct. 2011, at 22:22, Carl Meyer wrote:
>
> >> In order to make deployment easier, I also recommend putting
> >> site-wide templates and templatetags in an application, and keeping
> >> TEMPLATE_DIRS empty, but that's a personal preference.
>
> > Just out of curiosity, why would you say it makes deployment easier to
> > put static assets and templates into an installed app, rather than using
> > TEMPLATE_DIRS/STATICFILES_DIRS? (Templatetags are a different issue;
> > those have to go in an app).
>
> I see two advantages:
> - everything is an app: there are no special directories to handle when you 
> build a package,
> - templates and static files work with the same settings in development and 
> production.
>
> These arguments aren't very strong:
> - you still have to ensure that static files and templates are properly 
> packaged within apps,
> - generally, you have different settings in development and production 
> anyway, and the overhead of changing TEMPLATE_DIRS/STATICFILES_DIRS is 
> negligible.
>
> That's why I said it's a personal preference, maybe even an aesthetic matter 
> :)
>
> Best regards,
>
> --
> Aymeric Augustin.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Sane defaults for Startapp and Startproject

[Rich Jones]

Having an example project to fork/fiddle with in the documentation is
a fair compromise.

svn co http://code.djangoproject.com/svn/django/trunk/ django-example

?

R

On Oct 21, 2:22 pm, Carl Meyer  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Rich,
>
> On 10/21/2011 10:21 AM, Rich Jones wrote:
>
> > How would you guys feel about a manage.py startexample
>
> > which would create an example application? A simple, templated hello
> > world with an example model and an example view and an example
> > template?
>
> Indifferent? I kinda feel like following the tutorial gives you this
> already, and I'm not real excited about having another "sample project"
> in core to maintain and update. OTOH I understand that a lot of people
> learn best by tweaking existing working code, and if this were done
> outside of core the people who most need it (beginners) are not likely
> to be aware of it. Maybe there'd be a way to make it a downloadable part
> of the docs rather than a management command?
>
> I'm not going to work on this or commit it, but if other people
> (including at least one core dev) are excited about it I wouldn't stand
> in the way. So I guess that's a -0.
>
> Carl
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk6huGUACgkQ8W4rlRKtE2dAWQCg6mKdlRHDkk+sPYJvafjyms5C
> Q2wAoN70oNfxh3vTzd4W7DqrUCzO/RD8
> =mCZ7
> -END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Announcing Django-Zappa - Serverless Django on AWS Lambda + API Gateway

[Rich Jones]

Hey guys!

(I also made this post to django-users, but I think the discussion here can 
be about ways that we can improve Django to work better on AWS Lambda. 
Forgive the double-post.)

I'm pleased to announce the release of Django-Zappa - a way to run 
serverless Django on AWS Lambda + API Gateway.

Now, with a single command, you can deploy your Django apps in an 
infinitely scalable, zero-configuration and incredibly cheap way!

Read the announcement post here: 
https://gun.io/blog/announcing-zappa-serverless-python-aws-lambda/
Watch a screencast here: 
https://www.youtube.com/watch?v=plUrbPN0xc8&feature=youtu.be
And see the code here: https://github.com/Miserlou/django-zappa

Comments, questions and pull requests are welcome!

It seems quite performant already, but I bet there are ways that we can 
improve Django to work better on Lambda. 

Enjoy,
Rich Jones

-- 
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/e211b4de-0910-4bf6-ac72-6a6cc39de9f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Announcing Django-Zappa - Serverless Django on AWS Lambda + API Gateway

[Rich Jones]

Yes, it calls is in a WSGI mode. I've found that response time is around 
80-100ms.

On Monday, February 8, 2016 at 5:02:00 PM UTC+1, Florian Apolloner wrote:
>
> Hi Rich,
>
> to quote from your blog post:
>
>> the server is created *after* the HTTP request comes in through API 
>> Gateway. It then turns the API Gateway request into normal Python WSGI, 
>> processes the request, and returns it back through the API Gateway to the 
>> client.
>>
>
> Doesn't that effectively mean you are running in a CGI like mode? If yes, 
> performance will suck, if no, you are still running persistent servers 
> somewhere, which would make me wonder why you do not have to pay for them 
> (memory…)
>
> Cheers,
> Florian
>

-- 
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/6255a648-3d7b-4d06-8258-dad81266d65c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Improving django.setup() and app loading performance

[Rich Jones]

(Originally posted this as a ticket, but we can have discussion here and 
leave the ticket  for just 
more specific discussion.)

I imagine that this is an area that hasn't really been given much 
consideration with regards to optimization, because it isn't relevant to 
normal Django deployments. However, with "serverless" deployments (those 
without any permanent infrastructure), this becomes quite relevant as we 
have to call setup() every request. 


So, I'd love to discuss ideas for performance optimizations to Django's 
setup method. (A sample output for profile is available here: ​
https://github.com/Miserlou/django-zappa/issues/24 )


For starters - can we load apps in parallel? 

-- 
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/f85a73b4-a4a3-40a0-9035-d17a609ded16%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Improving django.setup() and app loading performance

[Rich Jones]

That might be true in theory.. but in practice?

Do any of the core/contrib/top100 apps actually depend on loading orders? 
I've never encountered that problem before, but I don't know.

It seems like we could easily get a 10x performance improvement by doing 
this in parallel by default, and have anything that _does_ have a 
dependency have some kind of DEPENDS_ON in the package init, so that the 
loader loop wouldn't complete until everything is ready. This would be a 
major benefit, and I don't think it would introduce all that much 
complexity.

-- 
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/f20ac9bc-2492-4b84-874f-6c1635eb15ab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Improving django.setup() and app loading performance

[Rich Jones]

@Aymeric
> In my opinion, the first concrete step would be to measure how much time 
is spent executing Django code rather than importing Python modules.

You can find a complete profile of a Django request as it goes through the 
complete request/response loop here: 
https://github.com/Miserlou/django-zappa/files/141600/profile.txt

Over 70% of the total request time is spent in django.setup() - so you can 
see why we have an incentive to improve this! 


@ Cristiano - 
> If with "serverless" you are talking deployments such as Amazon Lambda or 
similar, I don't think setup is called on every request, at least for AWS 
Lambda, the enviorment is cached so it will only happen once each time it 
needs to scale up. Are there any other issues?

You're halfway there, but the process is more complicated than that. The 
code is cached, not the internal state of the machine. You can follow our 
progress here: https://github.com/Miserlou/django-zappa/

But - another type caching could be another possibility. Can anybody think 
of any arrangements where we could perhaps call setup() with 
"pre-loaded"/cached applications? 

-- 
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/a7d47b1d-7805-4085-a0d3-b7270c5966d3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Improving django.setup() and app loading performance

[Rich Jones]

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  
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/69403014-64e1-473a-86fc-88ccaea7ac91%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Improving django.setup() and app loading performance

[Rich Jones]

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/eee4285f-243b-494a-ae20-7678c8d4cb7c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Improving django.setup() and app loading performance

[Rich Jones]

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.

Re: Improving django.setup() and app loading performance

[Rich Jones]

As I suspected, moving setup() outside of the handler had a negligible 
effect - in fact the test showed a slight drop in performance. :(

Testing from httping. From Berlin to US-East-1:

Before:
--- 
https://arb9clq9k9.execute-api.us-east-1.amazonaws.com/unicode/json_example/ 
ping statistics ---
52 connects, 52 ok, 0.00% failed, time 56636ms
round-trip min/avg/max = 59.1/104.8/301.9 ms

After:
--- 
https://arb9clq9k9.execute-api.us-east-1.amazonaws.com/unicode/json_example/ 
ping statistics ---
51 connects, 51 ok, 0.00% failed, time 57306ms
round-trip min/avg/max = 61.8/128.7/523.2 ms

It was a nice thought though!

-- 
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/489869be-cde5-4833-9406-1be565f7900d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Improving django.setup() and app loading performance

[Rich Jones]

That certainly could have something to do with it - there isn't very much 
transparency about how API Gateway works. It's super new and pretty janky, 
TBQH. However, I think that the behavior describing is not what's expected 
- the caching seems to be for the assets of the whole environment, not of 
anything that's computed - whether or not they are held in memory or read 
from disk.

[[ Also, obviously it's not a fair comparison, but I thought I'd include 
these numbers for reference:
--- http://djangoproject.com/ ping statistics ---
52 connects, 52 ok, 0.00% failed, time 68473ms
round-trip min/avg/max = 227.9/329.3/1909.3 ms ]]

So, I think the interesting things to explore would be:
 - Loading apps in parallel
 - "Pre-loading" apps before app deployment, then loading that cached state 
at runtime. I guess I'd need to know more about what it means to "load" an 
app to see if that makes any sense at all.

I imagine the former is probably more feasible. I understand the aversion 
to non-determinism, but I think that shouldn't matter as long as there is a 
way to define inter-app dependencies.

-- 
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/fbc32a62-4d29-4ecf-bbd6-a5a2256b564b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Improving django.setup() and app loading performance

[Rich Jones]

Hm. This is the downside of cloud services - we cannot look under the hood.

Since I think that since this is something we _want_ cached, and because it 
will make the function being executed shorter in length - it is a good code 
decision to make. Thank you for the idea! However, it looks like the actual 
result is negligible in terms of round-trip time.

Maybe you can try with httping and show me your times? Or give django-zappa 
a shot yourself! This is the app I'm testing with: 
https://github.com/Miserlou/django-helloworld

-- 
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/aa2ce7e4-647b-4f3e-ad2a-732f0d6ee0ac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Improving django.setup() and app loading performance

[Rich Jones]

Ah, interesting! Thanks for tracking that down.

In chat we basically discovered that the intercontinental latency and 
shoddy wifi connections were responsible for a lot of the confusion.

Testing from a US-based fiber connection, we got results of ~40ms in both 
scenarios.

 --- 
https://arb9clq9k9.execute-api.us-east-1.amazonaws.com/unicode/json_example/ 
ping statistics ---
16 connects, 16 ok, 0.00% failed, time 15989ms
round-trip min/avg/max = 32.7/42.3/142.4 ms

So, there you have it! As if you needed more of a reason to get down with 
Zappa?! :-D

(Now, that's with a naive-example. Expect this thread to get bumped when we 
start really hitting the databases..)

-- 
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/32553dde-3106-4e65-b7a9-d05ad0256b50%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.