WordPress toimii lähtökohtaisesti synkronisesti: käyttäjän HTTP-request käynnistää PHP-prosessin, suorittaa kaiken logiikan ja palauttaa vastauksen. Tämä toimii pienissä sivustoissa hyvin, mutta raskaat operaatiot alkavat nopeasti aiheuttaa hitautta, timeoutteja ja palvelinkuormaa.
Async processing eli taustaprosessointi ratkaisee tämän siirtämällä raskaat tehtävät pois varsinaisesta requestista.
Tyypillisiä async-tehtäviä:
- kuvien optimointi
- import/export
- API-synkronointi
- sähköpostien lähetys
- webhook-käsittely
- cache warming
- AI-prosessointi
- raporttien generointi
Miksi synkroninen prosessointi on ongelma
Huono flow:
User Request
↓
Heavy Task
↓
Timeout
↓
Slow UX
Ongelmat:
- korkea TTFB
- PHP timeoutit
- memory exhaustion
- huono käyttäjäkokemus
Async processingin perusidea
Parempi malli:
User Request
↓
Queue Job
↓
Immediate Response
↓
Background Worker
Käyttäjä ei odota raskasta operaatiota.
1. WordPress ei sisällä oikeaa queue-järjestelmää
Core tarjoaa:
WP-Cron
Mutta se ei ole oikea background worker.
- riippuu liikenteestä
- ei ole tarkka ajastin
- ei skaalaudu hyvin
2. Yksinkertainen async request
Kevyin tapa:
wp_remote_post(
admin_url('admin-ajax.php'),
[
'blocking' => false
]
);
Tämä “fire-and-forget” käynnistää taustaprosessin.
3. Action Scheduler
Paras käytännön ratkaisu moniin projekteihin.
Käytössä mm:
- WooCommerce
- suurissa plugin-ekosysteemeissä
Esimerkki:
as_enqueue_async_action(
'process_import',
['file_id' => 123]
);
4. Scheduled actions
Ajastettu jobi:
as_schedule_single_action(
time() + 60,
'send_report'
);
5. Hook handler
add_action('process_import', function($file_id) {
// Heavy processing
});
6. Queue-pohjainen arkkitehtuuri
Moderni flow:
Request
↓
Queue
↓
Worker
↓
Retry Logic
↓
Completion
7. Batch processing
Älä käsittele kaikkea yhdellä kertaa.
Huono:
Import 50k rows yhdessä requestissa
Parempi:
500 rows per batch
8. Stateful processing
Pitkissä jobeissa pitää tallentaa tila:
processed_rows = 1500
Tallennus:
- custom table
- transient
- Redis
9. Retry logic
Taustajobit epäonnistuvat joskus.
Tarvitset:
Fail
↓
Retry
↓
Max Attempts
↓
Dead Queue
10. Dead queue
Jos job failaa jatkuvasti:
failed_jobs
Näin bugit löytyvät helposti.
11. WP-Cron ongelmat
WP-Cron triggeröityy:
vain liikenteen yhteydessä
Hiljaisella sivustolla jobit eivät välttämättä käynnisty ajallaan.
12. Oikea server cron
Parempi ratkaisu:
*/1 * * * * php wp-cron.php
Tai:
wp cron event run --due-now
13. Queue storage
Vaihtoehtoja:
- wp_options
- custom tables
- Redis
- RabbitMQ
- SQS
Pienissä projekteissa custom table on usein paras.
14. Redis queue
Nopea ratkaisu korkeaan volyymiin:
Push Job
↓
Redis List
↓
Worker consumes
15. Async REST processing
REST endpoint:
POST /import
↓
job queued
↓
202 Accepted
Ei:
odota importin valmistumista
16. Background image processing
Tyypillinen pipeline:
Upload
↓
Queue
↓
Resize
↓
WebP conversion
↓
CDN purge
17. Email queue
Älä lähetä sähköposteja requestissa.
Huono:
Checkout
↓
SMTP timeout
↓
slow checkout
Parempi:
Checkout
↓
Queue email
↓
Background send
18. API sync async-mallilla
Ulkoiset API:t ovat hitaita.
Async-rakenne:
Webhook
↓
Queue
↓
Sync worker
↓
Retry
19. Monitorointi
Seuraa:
- queue length
- failed jobs
- retry count
- processing duration
- memory usage
20. Memory management
Pitkät workerit voivat vuotaa muistia.
Ratkaisut:
- restart workers
- batch limits
- explicit cleanup
21. Locking ja race conditions
Sama job ei saa käynnistyä kahdesti.
Käytä:
mutex
transient lock
redis lock
22. High-scale architecture
Enterprise-ratkaisu:
WordPress
↓
Queue Broker
↓
Worker Cluster
↓
Monitoring
23. Async processing WooCommercessa
Erityisen tärkeä:
- order sync
- inventory sync
- analytics
- exports
- subscription renewals
24. Yleisimmät virheet
- raskaat sync-operaatiot
- WP-Croniin luottaminen suurissa järjestelmissä
- ei retry-logiikkaa
- kaikki yhdessä batchissa
- ei monitorointia
- ei lockingia
25. Paras moderni async-stack
Skaalautuva WordPress async-arkkitehtuuri:
REST/API/Event
↓
Queue
↓
Background Workers
↓
Retry + Logging
↓
Completion Hooks
Yhteenveto
Async processing on yksi tärkeimmistä tavoista tehdä WordPressistä skaalautuva ja responsiivinen myös raskaissa ympäristöissä. Kun hitaat operaatiot siirretään queue-pohjisiin taustaprosesseihin, käyttäjäkokemus paranee merkittävästi ja palvelinkuorma pysyy hallittavana.
Hyvin rakennettu async-arkkitehtuuri sisältää queue-järjestelmän, retry-logiikan, batch processingin ja monitoroinnin. Näin WordPress pystyy käsittelemään suuria määriä dataa ja integraatioita ilman timeoutteja tai hitaita requesteja.