Sicurezza

Gestire Picchi di Traffico su WordPress

4 min di lettura

La campagna TV parte domani. O il prodotto diventa virale su TikTok. 10× il traffico normale in poche ore. Il tuo WordPress è pronto?

Anatomia di un Picco di Traffico

# Traffico normale:
100 visitatori/ora → 2 visite/minuto

# Picco da campagna TV:
1.000 visitatori/ora → 17 visite/minuto

# Viralità social:
10.000+ visitatori/ora → 167 visite/minuto

# WordPress standard non cachato:
- Può gestire: ~50 richieste/secondo
- Con DB query pesanti: ~5-10 richieste/secondo
- Risultato: crash

1. Preparazione Pre-Lancio (48 ore prima)

Audit Rapido

# Controlla query lente
# In wp-config.php (temporaneo!)
define( 'SAVEQUERIES', true );

# Nel footer:
if ( current_user_can( 'administrator' ) && defined( 'SAVEQUERIES' ) ) {
    global $wpdb;
    echo '';
    echo '';
}

# Target per landing page:
# < 20 query, < 0.1s tempo totale

Checklist Pre-Lancio

□ Cache pagina attiva e verificata
□ CDN configurato e testato
□ Immagini ottimizzate (WebP, lazy load)
□ Plugin inutili disattivati
□ Cron spostato su system cron
□ Autosalvataggio/revisioni limitati
□ Monitoring attivo
□ Piano B hosting se serve scale-up

2. Full Page Cache: Non Opzionale

# Senza cache:
Richiesta → PHP → WordPress → MySQL → Rendering → Risposta
Tempo: 500ms-2s per richiesta
Capacità: 10-50 req/sec

# Con cache pagina:
Richiesta → HTML statico → Risposta
Tempo: 10-50ms per richiesta
Capacità: 500-2000 req/sec

# Differenza: 50-100× più capacità!

Configurazione Aggressiva per Picchi

# Durante il picco, massimizza TTL cache

# Redis Object Cache (se disponibile)
define( 'wp_REDIS_MAXTTL', 86400 ); // 24 ore

# .htaccess - Browser cache aggressivo

    ExpiresActive On
    ExpiresByType text/html "access plus 5 minutes"
    ExpiresByType text/css "access plus 1 week"
    ExpiresByType application/javascript "access plus 1 week"
    ExpiresByType image/webp "access plus 1 month"

3. CDN Come Prima Linea di Difesa

# Cloudflare - Configurazione "Under Attack Lite"

1. Page Rules per landing principale:
   /landing-campagna/*
   → Cache Level: Cache Everything
   → Edge Cache TTL: 1 day
   → Browser Cache TTL: 4 hours

2. Durante picco attivo:
   → Argo Smart Routing (se disponibile)
   → Always Online: ON
   → Tiered Caching: ON

# Risultato: 95%+ richieste servite da edge
# Il tuo server vede solo il 5%

Test: Simula il Carico

# Con Apache Bench (già installato su Mac/Linux)
ab -n 1000 -c 50 https://tuosito.it/landing/

# Interpreta risultati:
# Requests per second: > 100 = OK per traffico normale
# Requests per second: > 500 = pronto per picchi
# Time per request: < 100ms = eccellente

# Con wrk (più realistico)
brew install wrk
wrk -t4 -c100 -d30s https://tuosito.it/landing/

4. Database: Il Collo di Bottiglia

# Query tipiche su landing WooCommerce:
SELECT * FROM wp_posts WHERE...           ×5
SELECT * FROM wp_postmeta WHERE...        ×20
SELECT * FROM wp_options WHERE...         ×10
SELECT * FROM wp_terms...                 ×8

# 43 query solo per caricare una pagina!
# Soluzione: Object Cache

Redis Object Cache

# Verifica se Redis disponibile
redis-cli ping  # Deve rispondere PONG

# wp-config.php
define( 'wp_REDIS_HOST', '127.0.0.1' );
define( 'wp_REDIS_PORT', 6379 );
define( 'wp_REDIS_DATABASE', 0 );

# Installa plugin
wp plugin install redis-cache --activate
wp redis enable

# Prima del picco: pre-popola cache
wp transient delete --all
curl -s https://tuosito.it/landing/ > /dev/null
# La seconda richiesta userà cache

5. Scale-Up di Emergenza

# Se il picco è IMMINENTE e non sei pronto:

OPZIONE 1: Page Cache statico temporaneo
# Genera HTML statico della landing
wget -O /var/www/landing-static.html https://tuosito.it/landing/
# Punta Nginx direttamente al file statico
location = /landing/ {
    try_files /landing-static.html =404;
}

OPZIONE 2: Serverless Edge
# Cloudflare Workers può servire HTML statico
# Costo: ~$5/milione di richieste
# Latenza: < 50ms globale

OPZIONE 3: Upgrade hosting temporaneo
# Molti provider permettono scale-up istantaneo
# DigitalOcean, Vultr, AWS: resize in 5 minuti

6. Monitoring Durante il Picco

# Setupuptime monitoring PRIMA del lancio

# UptimeRobot (free)
- Ping ogni 1 minuto
- Alert via SMS immediatamente

# Metriche da monitorare:
- Uptime (ovvio)
- Response time (< 500ms)
- Error rate (< 0.1%)
- CPU server (< 80%)
- RAM server (< 90%)
- MySQL connections (< limit)

Alert Proattivi

# Script monitoring (cron ogni minuto)
#!/bin/bash
RESPONSE_TIME=$(curl -o /dev/null -s -w '%{time_total}' https://tuosito.it)
if (( $(echo "$RESPONSE_TIME > 2" | bc -l) )); then
    curl -X POST "https://hooks.slack.com/..." \
         -d '{"text":"⚠️ Response time alto: '$RESPONSE_TIME's"}'
fi

7. Post-Picco: Analisi

# Metriche da raccogliere:
- Picco massimo visitatori/minuto
- % cache HIT vs MISS
- Errori 5xx totali
- Tempo medio risposta
- Conversioni durante picco

# Report per il cliente:
"Durante la campagna:
 - 12.500 visitatori in 2 ore
 - Uptime 99.97%
 - Tempo risposta medio: 180ms
 - 0 errori server
 - Cache HIT rate: 94%"

Hai una campagna in arrivo? Facciamo un audit pre-lancio del tuo WordPress per garantire che regga il carico. Contattaci con almeno 1 settimana di anticipo.

Articoli correlati