SpinupWP

• Goal: fast and stable WordPress on SpinupWP (Bricks + many plugins + large uploads) ✅
• XML-RPC in WordPress: what it is 🧩

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

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

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.

XML-RPC in WordPress: what it is 🧩

XML-RPC is a WordPress feature (available at https://your-site.com/xmlrpc.php) that lets external apps/services communicate with your site using a remote procedure call protocol (XML over HTTP).

Common legitimate uses

• Jetpack (some features rely on XML-RPC depending on configuration)
• Mobile/desktop apps that publish posts remotely
• Some automation/integration tools
• Historically: pingbacks/trackbacks (these are largely outdated and often abused)

---

Why people disable it 🔒

XML-RPC is not “insecure by default,” but it’s a frequent target because:

1. Brute-force login attempts
   • Attackers can try many passwords efficiently via system.multicall.
2. DDoS amplification / abuse
   • Especially via pingback mechanisms on sites that allow it.
3. It’s often unnecessary
   • Many modern setups use the REST API instead.

---

Should you disable it in SpinupWP? ✅

Recommended default

If you don’t explicitly need XML-RPC, then yes—disable it. This is a common hardening step and usually reduces attack noise meaningfully.

Keep it enabled if you rely on it

Don’t disable (or disable partially) if you use:

• Jetpack features that require XML-RPC
• A mobile publishing app or legacy integration that depends on xmlrpc.php
• Certain third-party services that still use XML-RPC to post/update content

If you’re unsure, check your logs for requests to /xmlrpc.php and confirm whether any are coming from known services you use.

---

What “disabling” should mean (best practice)

Ideally, you want one of these outcomes:

1. Block XML-RPC entirely
   Best if you never use it.
2. Disable only pingbacks (but keep other methods)
   Useful if you need XML-RPC for publishing/Jetpack but want to stop common abuse.

SpinupWP typically offers server-level controls (e.g., Nginx rules) or guidance to block xmlrpc.php. If you tell me how you’re planning to disable it (SpinupWP toggle, custom Nginx snippet, plugin), I can advise the safest approach.

---

Quick decision checklist 🧠

• You use Jetpack and depend on its remote features → Don’t disable blindly (consider disabling pingbacks only).
• You never publish remotely, don’t use Jetpack, and don’t need legacy integrations → Disable it.
• You’re getting lots of suspicious hits to /xmlrpc.php → Disable or restrict it (and consider adding rate-limiting/WAF).

---

If you share whether you use Jetpack, any mobile publishing, or specific integrations, I’ll recommend the most appropriate SpinupWP configuration.