Async Job Execution mit Symfony2

Preview:

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

wolfgang.muender@tngtech.com

Recommended