• sugar_in_your_tea@sh.itjust.works
    link
    fedilink
    arrow-up
    2
    ·
    edit-2
    14 days ago

    Then you need to break up your problem into processes. Python doesn’t really do multi-threading (hopefully that changes with the GIL going away), but most things can scale reasonably well in a process pool if you manage the worker queue properly (e.g. RabbitMQ works well).

    It’s not as good as proper threadimg, but it’s a lot simpler and easier to scale horizontally. You can later rewrite certain parts if hosting costs become a larger issue than dev costs.

    • hark@lemmy.world
      link
      fedilink
      arrow-up
      3
      ·
      14 days ago

      A process pool means extra copying of data around which incurs a huge cost and this is made worse by the tendency for parallel-processing-friendly workloads often consisting of large amounts of data.

      • sugar_in_your_tea@sh.itjust.works
        link
        fedilink
        arrow-up
        2
        ·
        14 days ago

        Yup, which is why you should try to limit the copying by designing your parallel processing algorithm around it. If you can’t, you would handle threading with a native library or something and scale vertical instead of horizontal. Or pick a different language if it’s a huge part of your app.

        But in a lot of cases, it’s reasonable to stick with Python and scale horizontally. That has value if you’re otherwise a Python shop.