Использование API Python/Flask в RHEL с тяжелыми задачами, связанными с вводом-выводом ⇐ Linux

[Anonymous]

ниже представлен дизайн моего приложения. как вы можете видеть, мои API-интерфейсы flask/python размещают API-интерфейсы веб-сокетов для некоторых действий внешнего интерфейса. Цель состоит в том, чтобы обеспечить быструю связь между интерфейсом и сервером, поскольку в нашей организации сотни одновременных пользователей получают доступ к интерфейсу и вносят изменения через интерфейс. такие вещи, как, например:

• нажатие кнопки, которая обновит запись в нашей внутренней базе данных.
• добавление комментариев к задачам, ответам и т. д.,

поскольку база пользователей очень огромна, и WS обеспечил суперскорость для быстрого получения обновлений с серверной части, мы начали хостинг API веб-сокета. теперь из-за этого мы перешли с Apache на Nginix, поскольку он имеет встроенную поддержку WS для обновления соединения. также мы выбрали комбинацию Gunicorn - eventlet в качестве сервера приложений, чтобы облегчить стиль WSGI для API-интерфейсов Flask.
Теперь проблема в том, что обновления из API-интерфейсов веб-сокетов во время разработки (запускаются через pycharm ui, когда Flask создает сервер разработки) это довольно быстро. но когда дело доходит до размещенной среды, как показано ниже, ее архитектура очень медленная.

на данный момент я понимаю,

поскольку количество рабочих = 1 - это конфигурация, которую мы должны были предоставить eventlet, один рабочий через зеленые потоки обрабатывает соединения/запросы ws, а также тем временем выполняет задачи, связанные с тяжелым вводом-выводом. когда я говорю «привязка ввода-вывода», я имею в виду сложные запросы к базе данных, и мы извлекаем сотни тысяч записей, в некоторых случаях это могут быть миллионы и обновление сотен тысяч повторных записей/удалений и т. д.,
поэтому один рабочий не может эффективно использовать 4-ядерный процессор, поэтому мой лучший выбор — внедрить брокера сообщений, такого как Redis, между ними, что облегчит eventlet использовать больше рабочих, позволяет 4. так что нагрузка на работника уменьшается на 1/4, а скорость может быть увеличена в 4 раза или даже больше.
как я уже сказал, это мое понимание, но мне нужна помощь экспертов.
также позвольте мне объяснить, почему flask APIS?
раньше приложение обслуживало все из серверной части, используя flask/kinja tempalte, мы переместили переднюю часть, чтобы реагировать, как вы можете см. на диаграмме дизайна, но серверная часть все еще flask.
мы скоро перейдем к быстрому API, но сейчас это не вариант, также переход от быстрого API может поддерживаться с точки зрения WSGI на ASGI, но компонент сервера приложений (eventlet / uvincorn в случае FAST API), ожидающий задач, связанных с вводом-выводом, не изменится, поэтому я чувствую, что проблема должна быть решена в любом случае.
Примечание: мы пытаемся создать пул (я думаю, пул потоков, в eventlet есть опция), чтобы выделить этот пул отдельно для задачи, связанной с вводом-выводом, но этот подход все еще находится в стадии разработки и пока не дал каких-либо лучших результатов в скорости.



Подробнее здесь: https://stackoverflow.com/questions/798 ... ound-tasks