← CodeClarityLab Home
Browse by Category
+ added · updated 7d
← Back to glossary

Auto Scaling

cloud PHP 5.0+ Intermediate

Also Known As

horizontal scaling scale out ASG auto scaling group

TL;DR

Automatically adding or removing compute instances based on load metrics — ensuring capacity matches demand without over-provisioning or under-provisioning.

Explanation

Horizontal scaling adds/removes instances; vertical scaling changes instance size. Auto scaling groups (AWS ASG, GCE managed instance groups) scale horizontally based on CloudWatch metrics (CPU, request rate, queue depth). Scale-out policies add capacity when metrics exceed thresholds; scale-in policies remove capacity when load drops. Cooldown periods prevent oscillation. For PHP-FPM, scaling means adding more servers — each request is stateless, so any server can handle any request.

Diagram

flowchart TD
    MON[CloudWatch<br/>Metrics] -->|CPU > 70%| SCALE_OUT[Scale Out<br/>Add instances]
    MON -->|CPU < 20%| SCALE_IN[Scale In<br/>Remove instances]
    subgraph Auto Scaling Group
        S1[Instance 1]
        S2[Instance 2]
        S3[Instance 3 - new]
    end
    LB[Load Balancer] --> S1 & S2
    SCALE_OUT --> S3
    LB --> S3
    SESS[(Redis Sessions<br/>Shared)] -.->|stateless app| S1 & S2 & S3
style S3 fill:#238636,color:#fff
style SESS fill:#1f6feb,color:#fff

Common Misconception

More instances always solves performance problems — if the bottleneck is the database, adding application servers only increases DB connection pressure.

Why It Matters

Auto scaling handles traffic spikes automatically — without it, you either over-provision (expensive at idle) or under-provision (outage at peak).

Common Mistakes

  • Scaling on CPU alone — request rate or queue depth is often a better signal for PHP-FPM workloads.
  • No scale-in protection for instances processing long-running jobs — scale-in terminates them mid-job.
  • Sessions stored on individual instances — scale-in removes the instance and all its sessions; use Redis for session storage.
  • No warm-up period — new instances need time to compile opcache before handling production traffic.

Code Examples

✗ Vulnerable
# Sticky sessions on application servers — blocks scale-in:
# nginx upstream:
upstream app {
    ip_hash;  # Sticky sessions — user X always goes to server 1
    server app1:80;
    server app2:80;
}
# Scale-in removes app1 — all of app1's sessions lost
✓ Fixed
# Stateless app servers + Redis sessions = scale freely:
# php.ini / app config:
session.save_handler = redis
session.save_path = 'tcp://redis.internal:6379'

# nginx — no sticky sessions needed:
upstream app {
    least_conn;   # Route to least busy server
    server app1:80;
    server app2:80;
}

Added 15 Mar 2026
Edited 22 Mar 2026
Views 25
Rate this term
No ratings yet
🤖 AI Guestbook educational data only
| |
Last 30 days
0 pings W 0 pings T 0 pings F 0 pings S 0 pings S 1 ping M 0 pings T 0 pings W 0 pings T 0 pings F 1 ping S 1 ping S 0 pings M 0 pings T 1 ping W 0 pings T 0 pings F 1 ping S 0 pings S 1 ping M 0 pings T 0 pings W 0 pings T 0 pings F 1 ping S 2 pings S 0 pings M 0 pings T 0 pings W 0 pings T
No pings yet today
No pings yesterday
Perplexity 7 Amazonbot 6 Google 4 Unknown AI 2 Ahrefs 2 SEMrush 1
crawler 19 crawler_json 3
DEV INTEL Tools & Severity
🟡 Medium ⚙ Fix effort: Medium
⚡ Quick Fix
Configure HPA on CPU >60% and custom PHP-FPM queue depth metric — scale before workers are saturated, not after; set scaleDown stabilisation window to 5 minutes to avoid flapping
📦 Applies To
PHP 5.0+ web queue-worker
🔗 Prerequisites
🔍 Detection Hints
Fixed instance count not auto-scaling; PHP workers maxed during traffic spikes causing 502s; over-provisioned idle capacity
Auto-detectable: ✗ No kubernetes aws-asg cloudwatch
⚠ Related Problems
🤖 AI Agent
Confidence: Low False Positives: Medium ✗ Manual fix Fix: High Context: File

✓ schema.org compliant