Я работаю над веб-сервисом, реализованным поверхNginx+gunicorn+Джанго, Клиентами являются приложения для смартфонов. Приложению необходимо выполнить несколько длительных вызовов внешних API (Facebook, Amazon S3 ...), поэтому сервер просто ставит задание в очередь на сервере заданий (используяСельдерей надRedis).

По мере возможности, когда сервер ставит задачу в очередь, он сразу же возвращается, и HTTP-соединение закрывается. Это прекрасно работает и позволяет серверу выдерживать очень высокую нагрузку.

client                   server                 job server
  .                        |                        |
  .                        |                        |
  |------HTTP request----->|                        |
  |                        |--------queue job------>|
  |<--------close----------|                        |
  .                        |                        |
  .                        |                        |

Но в некоторых случаях клиент должен получить результат, как только работа будет завершена. К сожалению, сервер не может связаться с клиентом после закрытия HTTP-соединения. Одним из решений было бы положиться на клиентское приложение, опрашивающее сервер каждые несколько секунд, пока задание не будет завершено. Я хотел бы избежать этого решения, если это возможно, главным образом потому, что оно будет препятствовать реактивности службы, а также потому, что оно будет загружать сервер многими ненужными запросами на опрос.

Короче говоря, я хотел бы, чтобы соединение HTTP работало и работало, ничего не делая (кроме, возможно, периодической отправки пробелов для поддержания соединения TCP, простокак Amazon S3), пока работа не будет выполнена, и сервер вернет результат.

client                   server                 job server
  .                        |                        |
  .                        |                        |
  |------HTTP request----->|                        |
  |                        |--------queue job------>|
  |<------keep-alive-------|                        |
  |         [...]          |                        |
  |<------keep-alive-------|                        |
  |                        |<--------result---------|
  |<----result + close-----|                        |
  .                        |                        |
  .                        |                        |

How can I implement long running HTTP connections in an efficient way, assuming the server is under very high load (it is not the case yet, but the goal to be able to sustain the highest possible load, with hundreds or thousands of requests per second)?

Выгрузка фактических заданий на другие серверы должна обеспечивать низкую загрузку ЦП на сервере, но как я могу избежать накапливания процессов и использования всей оперативной памяти сервера или потери входящих запросов из-за слишком большого количества открытых соединений?

Вероятно, это в основном вопрос правильной настройки nginx и gunicorn. Я прочитал немного оасинхронные рабочие, основанные на гринлетах в оружейном: в документации сказано, что асинхронные рабочие используются & quot;Applications making long blocking calls (Ie, external web services)"Это звучит идеально. Там также написано & quot;In general, an application should be able to make use of these worker classes with no changes& Quot ;. Это звучит великолепно. Есть какие-либо отзывы по этому поводу?

Спасибо за ваши советы.