Как я могу масштабировать веб-приложение с длительным временем отклика, которое в настоящее время использует django

Я пишу веб-приложение с django на стороне сервера. Серверу требуется ~ 4 секунды, чтобы сгенерировать ответ пользователю. Он использует API погоды. Мое приложение должно сделать ~ 50 запросов к этому API для каждого запроса пользователя.

На стороне сервера используется urllib python для использования API погоды. Я использовал потоки Python, чтобы ускорить процесс, потому что urllib является синхронным. Я использую wsgi с apache. Проблема в том, что стек wsgi полностью синхронен, и когда многие пользователи используют мое приложение, им приходится ждать завершения запроса друг друга. Поскольку каждый запрос занимает ~4 секунды, это неприемлемо.

Я немного застрял, что мне делать?
Спасибо.


django multithreading api web-applications mod-wsgi
person refik    schedule 11.11.2010    source источник
comment
Можете ли вы предварительно кэшировать данные вместо того, чтобы делать это во время запроса?   -  person Brian Tol    schedule 12.11.2010
comment
В зависимости от пользователя может потребоваться запрос данных для любой точки земного шара. Мне нужно кэшировать данные о погоде всего мира, и это слишком много. Плюс ежечасно меняется.   -  person refik    schedule 12.11.2010

Ответы (2)


arrow_upward
0
arrow_downward

Если вы используете mod_wsgi в многопоточной конфигурации или даже в конфигурации с несколькими процессами, один запрос не должен блокировать выполнение другого запроса. Они должны иметь возможность работать одновременно. Если вы используете многопоточную конфигурацию, уверены ли вы, что не используете какой-либо механизм блокировки для какого-либо ресурса в вашем собственном приложении, который препятствует выполнению запросов через один и тот же раздел кода? Другая возможность заключается в том, что вы неправильно настроили режим демона Apache MPM и/или mod_wsgi, чтобы предотвратить одновременные запросы.

В любом случае, как упоминалось в другом ответе, вам гораздо лучше рассмотреть стратегии кэширования, чтобы в первую очередь избежать поиска погоды или разгрузки на клиенте.

person Graham Dumpleton    schedule 11.11.2010
comment
Я настроил wsgi, как описано здесь: bit.ly/EaatF Не думаю, что я что-то запираю. Я не делал ничего особенного с моей конфигурацией apache, так что, возможно, это проблема, как вы сказали. Я посмотрю на это. Поиск погоды необходим на стороне сервера, я прокомментировал это под этим ответом. - person refik; 12.11.2010
comment
Ваш комментарий «Я использую потоки для получения URL-адресов» не имеет смысла. Вам не нужно создавать отдельные потоки для извлечения данных, если только вы фактически не запускаете несколько фоновых потоков одновременно, чтобы попытаться распараллелить запросы, а затем дождаться их завершения. Это то, что вы делаете? - person Graham Dumpleton; 12.11.2010
comment
Кстати, вам действительно следует изучить режим демона mod_wsgi. Если бы вы следовали только этим инструкциям, вы бы работали во встроенном режиме, который, если вы не настроите Apache MPM должным образом, может вызвать проблемы. -spike-and-excessive-memory-usage.html" rel="nofollow noreferrer">blog.dscpl.com.au/2009/03/'. - person Graham Dumpleton; 12.11.2010
comment
Да именно этим я и занимаюсь. Что касается инструкций, которым я следовал (которые, как я понял, вы написали :), они также показывают использование режима демона. Я использую версию демона. Сообщение в блоге действительно помогло мне понять вещи, кстати. - person refik; 12.11.2010
comment
Я понял, что механизм блокировки был моей проблемой, как вы сказали. Я исправил это, и теперь wsgi работает в режиме демона. Спасибо - person refik; 12.11.2010

arrow_upward
0
arrow_downward

50 запросов к внешнему ресурсу на запрос, вероятно, нехорошо, и, вероятно, вовсе не обязательно.

Погода не меняется так быстро, поэтому вы, вероятно, можете получить огромную выгоду, просто кэшируя результаты на некоторое время. Тогда не имеет значения, сколько запросов вы получаете, вам не нужно делать больше нескольких запросов в день.

Если это не ваша ситуация, вы можете заставить клиента сделать всю работу за вас. Рефакторинг кода, чтобы агрегация API погоды происходила на клиенте в javascript, а не направлялась через сервер.

Изменить: основываясь на опубликованных вами комментариях, то, о чем вы просите, вероятно, не может быть оптимизировано в рамках ограничений используемого вами API. Проблема в том, что служба хорошо справляется с абстрагированием различий во многих источниках информации о погоде, которые они объединяют в запрос ближайшего местоположения. ведь метеостанции предоставляют только точечные данные.

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

Без этого или кэширования вам просто не повезло.

person SingleNegationElimination    schedule 11.11.2010
comment
50 запросов выполняются для 50 различных местоположений. Пользователь выбирает место на карте, и приложение должно посмотреть погоду в 50 точках вокруг этого места. Это необходимо для оценки. Местоположение, которое выбирает пользователь, может быть любой точкой на земле, поэтому я не уверен, что кеширование поможет. Я также думал об использовании javascript, но политика использования API не позволяет сделать мой ключ API общедоступным, так что это не похоже на вариант. - person refik; 12.11.2010
comment
Поддерживает ли API запросы ограничивающей рамки? - person SingleNegationElimination; 12.11.2010
comment
К сожалению нет. Это то, что я использую: bit.ly/dlIAIp Этот API, кажется, единственный, который я смог найти, который может запрашиваться с широтой/долготой - person refik; 12.11.2010