• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Async Job Execution mit Symfony2
 

Async Job Execution mit Symfony2

on

  • 643 views

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 ...

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.

Statistics

Views

Total Views
643
Views on SlideShare
643
Embed Views
0

Actions

Likes
0
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Async Job Execution mit Symfony2 Async Job Execution mit Symfony2 Presentation Transcript

    • ASYNC JOB EXECUTION MIT SYMFONY2 ‘Die Welt ist nicht genug’Wolfgang Münder
    • Browser Apache PHP Timeout
    • Browser Apache PHP PHP Done
    • 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 SPEICHER Lass 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
    • TESTS‘Ein Quantum Trost’
    • 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ändigwolfgang.muender@tngtech.com