2012-05-22 4 views
1

Я хочу, чтобы приложение google app engine appappapp для приложения google появилось как можно быстрее (создайте новый экземпляр приложения). Мне было интересно, какие очевидные замедления я должен следить (я знаю .. преждевременная оптимизация, но я не хочу делать массивный рефактор в конце, если я могу помочь)как импортировать модели и обработчики в webapp2, чтобы обеспечить быстрый запуск нового экземпляра приложения.

У меня есть папка иерархия похожа на это:

-root_folder 
__init__.py 
main.py 
config.py 
routes.py 
models.py 
gviz_api.py 
... 20 more .py files 
-web_folder 
    __init__.py 
    some_handlers.py 
    more_handlers.py 
    20 more.py files 
    .. 
-data_model_folder 
    __init__.py 
    some_models.py 
    more_ndb_models.py 
    10 more model files 
-many more folders e.g. templates, simpleauth etc. 

в main.py, я создаю экземпляр приложения с помощью маршрутизатора (маршрутизатор импортируется из routes.py). routes.py импортирует каждый обработчик (назначая каждому маршруту обработчик). Каждый обработчик импортирует почти каждый datamodel. Означает ли это, что мое приложение очень медленно создает новый экземпляр приложения?

Я ожидаю, что к концу моего проекта будет около 100 обработчиков и 30 моделей данных, хотя многие из них будут редко использоваться.

импортировать модель данных (из внутри some_handlers.py)

просто следующий достаточно быстро:

from root_folder.data_model_folder.more_ndb_models import special_model

Должен ли я смотреть использовать конфигурационный/реестр?

ответ

2

Обычно замедление связано с импортом больших фреймворков, а не с большим количеством кода приложения. Поэтому я не стал бы слишком беспокоиться об этом, даже если у вас есть 100.py файлов. (Поверьте мне, 100 не так уж много ...) Я также посмотрю запросы на разминку.

Я не большой поклонник ленивых трюков с импортом - они могут создавать сложные режимы сбоев в кросс-кейсах (т. Е. Трудно отлаживать), и они не пользуются дополнительными возможностями, которые App Engine предоставляет загружающим запросам (проверьте свои журналы для того, что он считает запросом на загрузку).

В частности, если вы не импортируете все классы моделей в начале, вы рискуете получить «Класс модели не найден для добрых« Х »ошибок.

+0

Это вне меня, как «класс модели не найден для добрых« X », может возникнуть - я не буду использовать ленивый импорт. Все, что вы упомянули, было очень полезно. –

+0

Также, под «большими каркасами», вы имеете в виду любой из них, включенных в движок приложения? например numpy и т. д. –

+1

«Класс модели, найденный для вида« X », может возникнуть, если вы получите закодированный ключ от пользователя и извлечете его из хранилища данных. Если тип ключа - X, но модуль, определяющий класс X, еще не импортирован, вы получаете эту ошибку, потому что для кода клиента должен быть класс X, чтобы построить результат. В больших рамках я в основном имел в виду Django; хотя и учитывается весь механизм приложения. :-) –

3

Webapp2 поддерживает lazily-imported handlers.

+0

Спасибо, так есть ли причина не использовать их для каждого маршрута? Также мой текущий метод импорта special_model pythonic? каждый файл __init__.py пуст. –

+0

Полагаю, мне нужно судить, что лучше. Если пользователь посещает handler1 и handler2, и оба handler1 и handler2 импортируют dbmodelx, то я дважды импортирую dbmodelx. (тогда как я мог бы поставить handler1 и handler2 в тот же модуль, тем самым только импортируя dbmodelx один раз). –

+0

Вот мои ответы на ваши вопросы: вы должны хорошо использовать ленивые обработчики импорта для всех маршрутов. Я делаю в своих приложениях. Для вашего второго вопроса: я бы использовал решение с меньшим количеством файлов. Локальный доступ к файлам в движке приложения невелик (люди java часто связывают все в файл jar, чтобы делать меньше файлов). И я считаю, что импорт в python кэшируется, поэтому импорт дважды не является дорогостоящим. – mjibson

 Смежные вопросы

  • Нет связанных вопросов^_^