Upload
wolfgang-muender
View
772
Download
0
Embed Size (px)
DESCRIPTION
Umfangreiche (Symfony2-) Applikationen machen es oftmals nötig größere BackEnd-Aufgaben asynchron auf mehrere Server zu verteilen. Ich möchte in diesem Vortrag ein generisches und leichtgewichtiges Setup für eine Symfony2 Applikation vorstellen. Als Beispiel ist hier (aus historischen Gründen) Gearman gewählt.
Citation preview
ASYNC JOB EXECUTION MIT SYMFONY2
‘Die Welt ist nicht genug’
Wolfgang Münder
Browser Apache PHP
Timeout
Browser
Done
Apache PHP PHP
PROBLEMSTELLUNG
• Hoher Zeitaufwand (Timeout!)
• Hoher Speicherbedarf
• User braucht Ergebnis nicht sofort
ANFORDERUNGEN
• Client-Prozesse
• Job-Server (ggf. mehrere)
•Worker auf mehreren Async-Servern
• Konfigurierbar
• Jobtypen (pro Worker)
• Job Priorität
• Worker-Instanzen pro Server
Image (c) http://gearman.org/
FRAMEWORK
• Job Queuing System
• Gearman
• Alternative: Message Queue
• ActiveMQ, RabbitMQ, ZeroMQ
CLIENT‘In tödlicher Mission’
CLIENT
• Best practice: \GearmanClient abstrahieren
• Symfony2 Service
• Schlankes Interface
• Job einstellen
• Job Status abrufen
• Job Output abrufen
• Überblick über alle Jobs/Jobtypen
JOB-SERVER‘Octopussy’
WORKER‘Stirb an einem anderen Tag’
SYMFONY2 FRISST SPEICHERLass es nicht lange leben.
TRENNE WORKER UND JOBS
WORKER COMMAND‘Leben und sterben lassen’
WORKER COMMAND
• Lebt ewig (supervisor)
• Registriert sich für Jobtypen (laut config)
• Startet Job Commands (proc_open)
•Organisiert Kommunikation
• Best practice: \GearmanWorker, \GearmanJob abstrahiert
WORKER COMMAND
•Nice to have
• Eigenes Logfile für Worker
• Logging mit hostname + process_id
JOB COMMAND‘Man lebt nur zweinmal’
JOB COMMAND
• Lebt nur für einen Job
• Vollständig entkoppelt vom Job-Framework
• Änderungen im Code sofort verfügbar
• Eigenes Command pro Jobtyp
JOB COMMAND
• Nice to have
• Eigenes Logfile pro Jobtyp
• Logging mit hostname + process_id
• Generische Fehlerbehandlung
• E-Mail im Fehlerfall
• Xhprof Profiling
• Login über serialisierten Token
‘Ein Quantum Trost’TESTS
TESTS
• Infrastruktur immer nur bedingt testbar
• Test-Client
• Prüft ob Jobs korrekt eingestellt werden
• Prüft ob Jobs korrekte Argumente erhalten
• Job Commands individuell testbar
GEARMANJob-Server auf mehreren Servern funktioniert nicht
GEARMANJob-Priorität nicht über Jobtypen hinweg
GEARMANOutput abrufen nur ‘händisch’
FAZIT
• Gearman löst Timeout-Probleme
• Generische Implementierung durch Abstraktion
• Gearman löst das Skalierungsproblem aber nicht vollständig