optimizing.rst 2.0 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667
  1. .. _optimizing:
  2. ============
  3. Optimizing
  4. ============
  5. Introduction
  6. ============
  7. The default configuration, like any good default, is full of compromises.
  8. It is not tweaked to be optimal for any single use case, but tries to
  9. find middle ground that works *well enough* for most situations.
  10. There are key optimizations to be done if your application is mainly
  11. processing lots of short tasks, and also if you have fewer but very
  12. long tasks.
  13. .. _optimizing-worker-settings:
  14. Worker Settings
  15. ===============
  16. .. _optimizing-prefetch-limit:
  17. Prefetch limit
  18. --------------
  19. *Prefetch* is a term inherited from AMQP, and it is often misunderstood.
  20. The prefetch limit is a limit for how many tasks a worker can reserve
  21. in advance. If this is set to zero, the worker will keep consuming
  22. messages *ad infinitum*, not respecting that there may be other
  23. available worker nodes that may even be able to process them sooner.
  24. In the worker the initial prefetch count is set by multiplying
  25. the :setting:`CELERYD_PREFETCH_MULTIPLIER` setting by the number
  26. of child worker processes.
  27. If you have many expensive tasks with a long duration you would want
  28. the multiplier value to be 1, which means it will only reserve one
  29. unacknowledged task per worker process at a time.
  30. However -- If you have lots of short tasks, and throughput/roundtrip latency
  31. is important to you, then you want this number to be large. Say 64, or 128
  32. for example, as the worker is able to process a lot more tasks/s if the
  33. messages have already been prefetched in memory. You may have to experiment
  34. to find the best value.
  35. If you have a combination of both very long and short tasks, then the best
  36. option is to use two worker nodes that is configured individually, and route
  37. the tasks accordingly (see :ref:`guide-routing`).
  38. Scenario 1: Lots of short tasks
  39. ===============================
  40. .. code-block:: python
  41. CELERYD_PREFETCH_MULTIPLIER = 128
  42. CELERY_DISABLE_RATE_LIMITS = True
  43. Scenario 2: Expensive tasks
  44. ===========================
  45. .. code-block:: python
  46. CELERYD_PREFETCH_MULTIPLIER = 1