огнестрельное и / или сельдерей: каким образом можно получить лучшее от обоих? - PullRequest
Новая
       12

огнестрельное и / или сельдерей: каким образом можно получить лучшее от обоих?

0 голосов
/ 19 декабря 2018

У меня есть приложение машинного обучения , которое использует флягу для предоставления API (для производства это не очень хорошая идея, но даже если я буду использовать Django в будущем идея вопроса не должна измениться.)

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

Когда число одновременных пользователей увеличилось, стало очевидно, что мы должны провести тестирование производительности на нем.Получается: он может обрабатывать 20 пользователей для 30 ГБ и 8 ядер машины без аутентификации и без какого-либо внешнего интерфейса.Что не похоже на хорошее число.

Я не знал, что есть такие вещи, как: сервер приложений, веб-сервер, сервер моделей.При поиске этой проблемы: gunicorn было хорошим приложением Python для сервера приложений.

  • Должен ли я использовать gunicorn или любой другой сервер приложений вместе с celery и почему
  • Если я удаляю celery и использую только gunicorn с приложением, я могу достичь параллелизма.Я где-то читал, celery не подходит для машинного обучения приложений.
  • Каковы цели gunicorn и celery.Как мы можем добиться лучшего из обоих?

Примечание : Основная цель - максимизировать параллелизм.Во время обслуживания в производстве будет добавлена ​​аутентификация.В процессе между ними может вступить в действие одно интерфейсное приложение.

1 Ответ

0 голосов
/ 19 декабря 2018

В колбе нет стыда.Если на самом деле вам просто нужна оболочка веб-API, flask, вероятно, гораздо лучший выбор, чем django (просто потому, что django огромен, и вы будете использовать только часть его возможностей).

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

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

  • Если вы не можете получить немедленный ответ, вы можетепусть вещи стоят в очереди.(cue celery, очередь задач, которую рабочие процессы могут использовать, чтобы получить следующую вещь, которая будет сделана, и передать результаты).Это работает лучше всего, если вам не нужен ответ в том же цикле запрос-ответ;например, вы отправляете работу от клиента, а они получают только подтверждение того, что работа была получена;Вам потребуется второй запрос, чтобы узнать о статусе задания и, возможно, результатах задания, если оно будет выполнено.

  • В качестве альтернативы, вместо Flask вы можете использовать websocketsили Tornado, чтобы вытолкнуть ответ клиенту, когда он доступен (в отличие от опроса пользователя о результатах или ожидания соединения через HTTP и запуска процесса сервера).

...