ядро приложения хранит все в памяти в соответствии с обычной семантикой Python, пока оно обслуживает один или несколько запросов в одном и том же процессе на одном и том же узле; если и когда ему нужны эти ресурсы, процесс завершается (поэтому в памяти не остается ничего, что было раньше), и новые процессы могут быть запущены (на том же узле или на разных узлах) в любое время для обслуживания запросов (независимо от того, обслуживают ли другие процессы) другие запросы все еще выполняются, или нет). Это очень похоже на модель fast-CGI: вы уверены в нормальной семантике в одном запросе, но кроме того, что в диапазоне от 0 до N (без верхнего предела) ваш код может запускать разные узлы, каждый из которых последовательно обслуживает все от 0 до K (без верхнего предела) разные запросы.
Вы ничего не можете сделать, чтобы «остаться в памяти» (для zipimported модулей или чего-либо еще).
Для полноты позвольте мне упомянуть memcache, который является явной подсказкой / запросом к среде выполнения движка приложения для сохранения чего-либо в специальной форме памяти, распределенной хеш-таблицей, которая используется всеми процессами, выполняющими ваш код - это сложно, хотя и не так невозможно использовать для импортированных модулей (вам понадобятся довольно сложные ловушки импорта), и я рекомендую против усилий, необходимых для разработки таких ловушек, потому что даже при наличии таких явных намеков среда выполнения движка приложения все еще может в любое время выбрать для удаления все, что вы ' В любом случае, мы спрятались в кеше.
Скорее - я не уверен, почему для работы cron, в частности, понадобится весь django или почему вы импортируете zip-файл, а не просто используете 1.0.2, которая теперь поставляется с механизмом приложения, для документы - хотите уточнить? Это может быть полезно для оптимизации.