Async Job Execution mit Symfony2

1,468 views

Published on

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.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Async Job Execution mit Symfony2

  1. 1. ASYNC JOB EXECUTION MIT SYMFONY2 ‘Die Welt ist nicht genug’Wolfgang Münder
  2. 2. Browser Apache PHP Timeout
  3. 3. Browser Apache PHP PHP Done
  4. 4. PROBLEMSTELLUNG• Hoher Zeitaufwand (Timeout!)• Hoher Speicherbedarf• User braucht Ergebnis nicht sofort
  5. 5. 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/
  6. 6. FRAMEWORK• Job Queuing System • Gearman• Alternative: Message Queue • ActiveMQ, RabbitMQ, ZeroMQ
  7. 7. CLIENT‘In tödlicher Mission’
  8. 8. CLIENT• Best practice: GearmanClient abstrahieren • Symfony2 Service• Schlankes Interface • Job einstellen • Job Status abrufen • Job Output abrufen • Überblick über alle Jobs/Jobtypen
  9. 9. JOB-SERVER ‘Octopussy’
  10. 10. WORKER‘Stirb an einem anderen Tag’
  11. 11. SYMFONY2 FRISST SPEICHER Lass es nicht lange leben.
  12. 12. TRENNE WORKER UND JOBS
  13. 13. WORKER COMMAND ‘Leben und sterben lassen’
  14. 14. WORKER COMMAND• Lebt ewig (supervisor)• Registriert sich für Jobtypen (laut config)• Startet Job Commands (proc_open)• Organisiert Kommunikation• Best practice: GearmanWorker, GearmanJob abstrahiert
  15. 15. WORKER COMMAND• Nice to have • Eigenes Logfile für Worker • Logging mit hostname + process_id
  16. 16. JOB COMMAND ‘Man lebt nur zweinmal’
  17. 17. JOB COMMAND• Lebt nur für einen Job• Vollständig entkoppelt vom Job-Framework• Änderungen im Code sofort verfügbar• Eigenes Command pro Jobtyp
  18. 18. 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
  19. 19. TESTS‘Ein Quantum Trost’
  20. 20. 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
  21. 21. GEARMANJob-Server auf mehreren Servern funktioniert nicht
  22. 22. GEARMANJob-Priorität nicht über Jobtypen hinweg
  23. 23. GEARMANOutput abrufen nur ‘händisch’
  24. 24. FAZIT• Gearman löst Timeout-Probleme• Generische Implementierung durch Abstraktion• Gearman löst das Skalierungsproblem aber nicht vollständigwolfgang.muender@tngtech.com

×