Twelve-Factor WordPress App #8: Concurrency

Factor #8: Concurrency

Scale out via the process model

Any computer program, once run, is represented by one or more processes. Web apps have taken a variety of process-execution forms. For example, PHP processes run as child processes of Apache, started on demand as needed by request volume.

In the twelve-factor app, processes are a first class citizen.

For example, HTTP requests may be handled by a web process, and long-running background tasks handled by a worker process.

This isn't anything too new for WordPress sites. As quoted above, both Apache and Nginx already have a method of scaling up needed processes.

In Practice

Of course it's not that simple.

Twelve-factor app processes should never daemonize or write PID files. Instead, rely on the operating system’s process manager (such as Upstart, a distributed process manager on a cloud platform, or a tool like Foreman in development) to manage output streams, respond to crashed processes, and handle user-initiated restarts and shutdowns.

If we consider PHP-FPM as an app process, we shouldn't daemonize it or write a PID file which is the standard setup.

So how do you manage your PHP-FPM processes? Use an init system like systemd or Upstart.

Read this article on running processes for more background on why you run programs instead of starting (daemonizing) them.

Turning a WordPress site into a Twelve-Factor App

  1. Codebase
  2. Dependencies
  3. Config
  4. Backing Services
  5. Build, release, run
  6. Processes
  7. Port binding
  8. Concurrency
  9. Disposability
  10. Dev/prod parity
  11. Logs
  12. Admin processes

Want to turn your WordPress site into a Twelve-factor App? Bedrock is a modern WordPress stack to help you get started with the best tools and practices.

Get our latest updates & occasional tips on building better WordPress sites

Follow @rootswp on Twitter