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.
