Skip to main content

Goal: fast and stable WordPress on SpinupWP (Bricks + many plugins + large uploads) ✅

❓ I use SpinupWP, and it allows you to configure the following settings. Please explain these settings to me and recommend what I should set: I’ll be using BricksBuilder and a whole range of other plugins. I also want to upload large files and edit large pages (a lot of content on a single page). My goal is to achieve excellent performance and stability.

Nginx

  • Client Max Body Size

  • Client Body Timeout

  • FastCGI Read Timeout

PHP

  • Upload Max File Size

  • Post Max Size

  • Memory Limit

  • Max Execution Time

  • Max File Uploads

  • Max Input Vars

  • Max Input Time

  • Worker Management

    • Static

      • Max Workers

      • Max Requests

    • Dynamic

      • Max Workers

      • Max Requests

      • Start Workers

      • Mind Idle Workers

      • Max Idle Workers

    • On-Demand

      • Max Workers

      • Max Requests

      • Idel Worker Timeout

SpinupWP is essentially letting you tune two layers:

  1. Nginx (the web server): controls request size limits and how long it will wait for data.

  2. PHP-FPM (PHP workers): controls how much PHP can consume per request and how many requests can run concurrently.

Below is what each setting does and what I’d set as a strong default for a “performance + stability” Bricks/WordPress site that also needs large uploads and large admin edits. (You can tighten later once you know your real needs.)

Nginx settings

1) Client Max Body Size

  • What it is: Maximum allowed size of an HTTP request body (uploads, big POST requests, some editor saves).

  • If too low: Uploads fail with 413 Request Entity Too Large.

  • Trade-off: Higher values allow bigger uploads, but also increase abuse potential (someone can try to send huge bodies).

Recommendation

  • Set to the largest file you realistically upload, with buffer.

    • Typical “safe but flexible”: 256M

    • If you truly upload big media/backups via WP: 512M (or 1G if you must)

  • If you’re using direct-to-object-storage uploads (S3, etc.), you can keep it lower.

2) Client Body Timeout

  • What it is: How long Nginx will wait to receive the request body from the client (e.g., slow upload connection).

  • If too low: Large uploads over slow connections fail mid-way (timeout).

  • Trade-off: Too high can keep connections open longer (slightly more exposure to slowloris-style behavior, though Nginx is good at handling this).

Recommendation

  • 120s–300s

    • Start at 300s if you regularly upload large files from typical home/office connections.

3) FastCGI Read Timeout

  • What it is: How long Nginx will wait for a response from PHP (via PHP-FPM).

  • If too low: Long operations (imports, image processing, complex saves) fail with 504 Gateway Timeout.

  • Trade-off: Too high can allow truly “stuck” PHP requests to tie up capacity longer.

Recommendation

  • 120s–300s

    • Start at 300s if you do imports, big edits, or heavy plugins.

    • For normal sites with no long operations, you’d keep it closer to 60–120s.

PHP (runtime) settings

4) Upload Max File Size (upload_max_filesize)

  • What it is: Max size for a single uploaded file handled by PHP.

  • If too low: WP media uploads fail.

Recommendation

  • Set based on your real uploads:

    • Common: 256M

    • Heavy media workflows: 512M

  • Must be ≤ Post Max Size (below).

5) Post Max Size (post_max_size)

  • What it is: Max size of the entire POST request (can include multiple files + form fields + editor payload).

  • If too low: Uploads or large editor saves can fail even if upload_max_filesize is high enough.

Recommendation

  • Set to a bit higher than upload_max_filesize:

    • If upload is 256M → post max 300M–320M

    • If upload is 512M → post max 600M–640M

6) Memory Limit (memory_limit)

  • What it is: Max memory PHP can use per request (front-end requests, WP admin, WP-Cron, AJAX, builder operations).

  • If too low: White screens, fatal errors, “Allowed memory size exhausted”, builder instability.

  • Trade-off: Higher per-request memory means fewer concurrent requests fit in RAM (important when combined with PHP worker count).

Recommendation (Bricks + plugins + big pages)

  • Start at 512M

  • If you see memory-related fatals or heavy Woo/ACF/SEO stacks: 768M (or 1024M only if you truly need it and have RAM headroom)

Stability tip: it’s usually better to run fewer PHP workers with enough memory than many workers that cause swapping/oom.

7) Max Execution Time (max_execution_time)

  • What it is: Max CPU time a PHP script is allowed to run.

  • If too low: Imports, backups, resizing, and some builder operations can fail.

  • Trade-off: Too high lets inefficient tasks run longer and hold workers.

Recommendation

  • 120s–300s

    • Start at 300s if you do imports/large operations.

    • If you don’t, 120s is often plenty.

8) Max File Uploads (max_file_uploads)

  • What it is: Max number of files that can be uploaded in one request.

  • If too low: Multi-file upload UIs may fail or partially upload.

Recommendation

  • 50 (safe default)

  • If you never bulk upload huge batches: 20 is fine.

9) Max Input Vars (max_input_vars)

  • What it is: Limits how many input fields PHP will accept (forms, page builder payloads, mega menus, complex admin screens).

  • If too low: Settings don’t save completely; missing fields; builder content or meta boxes not persisting.

  • Trade-off: Higher values slightly increase parsing overhead and can be abused (but typically fine behind WP auth).

Recommendation (large builder pages)

  • Start at 10,000

  • If you have extremely large pages / many dynamic fields: 20,000

  • Avoid absurdly high numbers unless you need them.

10) Max Input Time (max_input_time)

  • What it is: Time limit for PHP to parse input data (POST/GET/file uploads).

  • If too low: Large POST payloads (big editor saves) can fail.

Recommendation

  • 120s–300s

    • Start at 300s for your use case.

PHP-FPM Worker Management (this is the big performance/stability lever)

PHP-FPM runs a pool of PHP “workers.” Each concurrent uncached request generally needs a worker. More workers = more concurrency, but also more RAM usage. Too many workers = memory pressure → swapping → slow site → crashes.

Choosing the mode: Static vs Dynamic vs On-Demand

  1. Static

    • Always keeps exactly Max Workers running.

    • Best for predictable, steady traffic and lowest latency.

    • Can waste RAM on quiet sites.

  2. Dynamic (usually best general-purpose choice) 🌿

    • Keeps a baseline and scales up/down with demand.

    • Great balance of responsiveness and RAM efficiency.

  3. On-Demand

    • Starts workers only when needed; kills them after idle timeout.

    • Efficient for very low traffic.

    • Slight latency spikes as workers spawn; can feel worse in WP admin if constantly cold-starting.

Recommendation

  • Use Dynamic for “excellent performance + stability” on a typical production WP server.

Worker parameters (what they mean + what to set)

A) Max Workers (pm.max_children)

  • What it is: Maximum number of PHP requests that can run at the same time.

  • If too low: Requests queue → slow TTFB under load, admin feels laggy when multiple users.

  • If too high: RAM exhaustion → swapping/oom → site instability.

How to size it (rule of thumb)

  • Estimate average memory per PHP worker under your workload:

    • many WP sites: 80–200MB per worker

    • heavy builders/admin ops can spike higher

  • Then ensure: max_workers × (avg worker RAM) fits comfortably in available RAM after OS + Nginx + DB + caches.

Recommendation (practical starting points)

  • If your server is 2GB RAM: 4–6 workers

  • 4GB RAM: 6–12 workers

  • 8GB RAM: 12–24 workers

  • If you set memory_limit=512M, do not assume each worker uses 512M—but plan conservatively.

B) Max Requests (pm.max_requests)

  • What it is: How many requests a worker handles before it’s recycled.

  • Why it matters: Mitigates memory leaks/fragmentation from plugins/themes over time.

  • Trade-off: Too low = more respawns (minor overhead).

Recommendation

  • 500–1000

    • Start at 500 if you run lots of plugins and want stability.

    • Use 1000 if everything is stable and you want slightly fewer respawns.

Dynamic mode-specific

C) Start Workers (pm.start_servers)

  • What it is: Workers spawned on PHP-FPM start/reload.

  • Recommendation

  • Set to about 25–50% of Max Workers

    • Example: max 12 → start 4–6

D) Min Idle Workers (pm.min_spare_servers)

  • What it is: Minimum number of idle workers to keep ready.

  • Recommendation

  • About 15–30% of Max Workers

    • Example: max 12 → min idle 2–4

E) Max Idle Workers (pm.max_spare_servers)

  • What it is: Maximum idle workers to keep around.

  • Recommendation

  • About 50–70% of Max Workers

    • Example: max 12 → max idle 6–8

On-Demand mode-specific

F) Idle Worker Timeout (pm.process_idle_timeout)

  • What it is: How long an idle worker lives before it’s killed.

  • Recommendation

  • 10s–30s

    • For WP admin comfort, lean 30s

    • For ultra-low-traffic efficiency, 10s–15s

Suggested “strong baseline” config (most Bricks sites)

Use this as a starting point, then adjust based on real usage. 📌

Nginx

  1. Client Max Body Size: 512M

  2. Client Body Timeout: 300s

  3. FastCGI Read Timeout: 300s

PHP

  1. Upload Max File Size: 512M

  2. Post Max Size: 640M

  3. Memory Limit: 512M (go 768M if you hit memory fatals)

  4. Max Execution Time: 300

  5. Max File Uploads: 50

  6. Max Input Vars: 10,000 (20,000 if large builder pages still don’t save fully)

  7. Max Input Time: 300

PHP-FPM (Dynamic)

  • Max Workers: depends on RAM:

    • 4GB RAM → 10

    • 8GB RAM → 18

  • Max Requests: 500

  • Start Workers: ~40% of max

  • Min Idle Workers: ~20% of max

  • Max Idle Workers: ~60% of max

Concrete examples:

  1. If 4GB RAM

    1. Max Workers: 10

    2. Max Requests: 500

    3. Start Workers: 4

    4. Min Idle Workers: 2

    5. Max Idle Workers: 6

  2. If 8GB RAM

    1. Max Workers: 18

    2. Max Requests: 500

    3. Start Workers: 6

    4. Min Idle Workers: 3

    5. Max Idle Workers: 10

Two quick guardrails (important for “stability”)

  1. Don’t oversubscribe workers

    • If you see swapping (disk activity high, load average high, site suddenly slow), reduce Max Workers first.

  2. Make sure limits agree

    • client_max_body_size (Nginx) must be ≥ post_max_size (PHP) must be ≥ upload_max_filesize (PHP), otherwise you get confusing failures.

If you tell me these 4 details, I can give a precise worker count ⚙️

  1. Server RAM (and whether DB is on the same server)

  2. CPU cores

  3. Traffic level (avg + peak concurrent visitors)

  4. Whether you run WooCommerce / membership / heavy search/filter plugins

I’ll then recommend an exact Dynamic worker configuration sized to your hardware and workload.

Back to top