Как лучше всего передавать большие файлы через приложение Django, размещенное на HEROKU

  1. HEROKU gives me H12 error on transferring the file to an API from my Django application ( Understood its a long running process and there is some memory/worker tradeoff I guess so. ) I am on one single hobby Dyno right now.
  2. The function just runs smoothly for around 50MB file. The file itself is coming from a different source ( requests python package )
  3. The idea is to build a file transfer utility using Django app on HEROKU. The file will not gets stored in my app side. Its just getting from point A and sending to point B.
  4. Went through multiple discussions along with the standard HEROKU documentations, however I am struggling in between in some concepts:
  • Действительно ли эта проблема будет решена с помощью фоновых задач? (Если ДА, то я ищу объяснение процесса, а не прямой способ сделать это, чтобы я мог оптимизировать свой поток)
    • .
  • Как упоминается в стандартной документации, они рекомендуют фоновые задачи с использованием пакета RQ для python, я использую Postgre SQL в данный момент. Нужно ли мне для этого устанавливать и управлять базой данных Redis? Связано ли это вообще с базой данных?
  • Некоторые рекомендуют использовать дополнительный Worker, помимо WEB worker, который у нас есть по умолчанию. Как это связано с моей проблемой?
    • Некоторые советуют добавить несколько рабочих, не уверен, как это решает проблему. Допустим, сегодня он начинает работать с большими файлами, используя фоновые задачи, что если нагрузка на пользователей одновременно увеличится. Как это повлияет на мое решение и как я должен спланировать план снижения рисков.
  • .
    • Если у кого-то здесь есть сильное понимание в отношении архитектуры, я готов выслушать ваш опыт и мысли. Также дайте мне знать, есть ли другой путь, кроме HEROKU, с точки зрения решения, который сделает это более легким для меня.
  • .

    • Ценю ваше ВРЕМЯ.

    Посмотрели ли вы возможность использования celery для запуска этого в качестве фоновой задачи?

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

    Действительно ли эта проблема будет решена с помощью фоновых задач? (Если ДА, то я нахожу объяснение процесса, чем прямой способ сделать это, чтобы я мог оптимизировать свой поток)

    .

    Да, это может быть решено с помощью фоновых задач. Если вы используете что-то вроде Celery, который имеет прямую поддержку django, вы запускаете другой экземпляр вашего приложения Django, но с другой командой запуска для Celery. Затем он продолжает читать новые задачи для выполнения и считывает имя задачи из очереди redis (или rabbitmq - в зависимости от того, что вы используете в качестве брокера), а затем выполняет эту задачу и обновляет статус обратно в redis (или брокер, который вы используете).

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

    Как упоминается в стандартной документации, они рекомендуют фоновые задачи с использованием пакета RQ для python, я использую Postgre SQL в данный момент. Нужно ли мне для этого устанавливать и управлять базой данных Redis? Связано ли это вообще с базой данных?

    Для использования фонового задания с Celery вам потребуется установить какой-либо брокер сообщений, например Redis или RabbitMQ

    Некоторые рекомендуют использовать дополнительный Worker, отличный от WEB worker, который мы имеем по умолчанию. Как это связано с моей проблемой?

    Не думаю, что это поможет в вашем случае

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

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

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

    .

    Я работал над несколькими проектами, где мы использовали Celery с фоновыми задачами для загрузки больших файлов. Это хорошо работало для наших случаев использования.

    Вот мое окончательное мнение по этому поводу после полной оценки, испытаний и предыдущих рекомендаций, сделанных здесь, спасибо @arun.

    1. HEROKU нужен web worker для обеспечения работы сайта, который занимает 512MB памяти, включая размер вашего slug, любые операции, которые вы выполняете, если они ниже этих пределов, должны быть в порядке.
    2. Кроме того, допустим, у вас есть сценарии, как указано выше, где большой файл приходит из одного исходного api и поступает в другой целевой api с приложением Django, вам придется:
    • Сначала вам придется запустить функцию загрузки файла как фоновый процесс, так как на ответ, который ожидает HEROKU, уйдет более 30 секунд. В противном случае вас ожидает ошибка H12. Решением этой проблемы является внедрение фоновых задач Django, в моем случае сработал Celery. Итак, Celery - это ваша функциональность приложения Django, работающая как фоновый обработчик, которому нужно собственное приложение Dyno (The Worker), которое можно масштабировать в будущем.
    • Чтобы заставить ваш Django WSGI (Frontend App) общаться с Celery (Background App), вам нужен брокер сообщений между ними, которым может быть HEROKU Redis, RabbitMQ, и т.д.
      • .
    • Во-вторых, проблемы здесь не решаются, даже если у вас есть новый Worker, выделенный для приложения Celery, ограничения памяти все равно будут действовать, поскольку это также Dyno с собственной памятью.
    • Чтобы преодолеть это, ваш модуль запросов Python должен загружать файл в потоке вместо прямой загрузки всего файла в один буфер памяти. Итерируйте и загружайте данные потока по частям и отправляйте части файла в целевую конечную точку.
      • .
    • Здесь даже размер чанка играет важную роль. Я не буду приводить здесь точное число, поскольку оно зависит от различных факторов:
      1. Не должен быть слишком маленьким, иначе передача займет больше времени.
      2. Не должен быть слишком большим, чтобы его мог обработать любой из серверов конечных точек источника/цели.
    Вернуться на верх