Skip to content

Latest commit

 

History

History
31 lines (25 loc) · 1.98 KB

production.md

File metadata and controls

31 lines (25 loc) · 1.98 KB
Raw

Production Usage

There are multiple tips and suggestions which must be acknowledged while running RoadRuner on production.

State and memory

State and memory are not shared between different worker instances but are shared for a single worker instance. Since a single worker typically process more than a single request, you should be careful about it:

  • Make sure to close all descriptors (especially in case of fatal exceptions).
  • [optional] consider calling gc_collect_cycles after each execution if you want to keep the memory low (this will slow down your application a bit).
  • Watch memory leaks - you have to be more picky about what components you use. Workers will be restarted in case of a memory leak but it should not be hard to completely avoid this issue by properly designing your application.
  • Avoid state pollution (i.e. globals or user data cache in memory).
  • Database connections and any pipe/socket is the potential point of failure. Simple way of dealing with it is to close all connections after each iteration. Note that it is not the most performant solution.

Configuration

  • Make sure NOT to listen 0.0.0.0 in RPC service (unless in Docker).
  • Connect to a worker using pipes for higher performance (Unix sockets just a bit slower).
  • Tweak your pool timings to the values you like.
  • A number of workers = number of CPU threads in your system, unless your application is IO bound, then pick the number heuristically.
  • Consider using maxJobs for your workers if you experience any issues with application stability over time.
  • RoadRunner is +40% performant using Keep-Alive connections.
  • Set memory limit to least 10-20% below max_memory_usage.
  • Since RoadRunner workers run from cli you need to enable OPcache in CLI via opcache.enable_cli=1.
  • Make sure to use health check endpoint when running rr in a cloud environment.
  • Use user option in the config to start workers processes from the particular user on Linux based systems.