Stabiele Job Queue server voor Linux

[Verwijderd]

Ik kan me wel 2 andere fora bedenken waar dit topic zou kunnen staan, NWOS en SWS, maar dit forum kan ook wel weer voor mijn volgende probleem:

Ik heb voor een project een Job Queue server nodig waarme ik jobs kan runnen op de achtergrond, Sync en Async.

Hier zijn een aantal goede pakketten voor, welke het beste eruit komen zijn:

- Gearman
- BeansMQ
- Rabbit


De hele lijst is:

0MQ
Amazon Simple Queue System (SQS)
Apache MQ
Apache Qpid
Beanstalkd
Dropr
Gearman (Perl system by Danga)
Gearman (C)
Microsoft Message Queuing (MSMQ)
Minimalist Queue Services (MQS) abandoned project
Q4M MySQL Pluggable storage engine
OpenAMQ
Open Source Message Queue (OSMQ)
Peafowl
RabbitMQ
Red Hat Enterprise MRG
Starling
Sun Java System Message Queue
Z Message Queue abandoned project


Ik ben aan de slag gegaan met Gearman, de reden hiervoor is dat dit een echte Queue server is voor jobs en de andere servers meer gebaseerd zijn op message servers. Opzich hetzelfde doel maar dan net wat anders.

Een nadeel waar ik tegenaan loop is persistence storage voor de queue. Ik wil namelijk de status van de queue kunnen achterhalen omdat ik dat nodig heb,

Gearman kan dit doormiddel van een Drizzle plugin, dit is een MySQL fork welke wel naar MySQL servers kan praten.

Het hele Drizzle verhaal is wat aan de buggy kant en op Gearman is er verder ook weinig activiteit. Gearman opzich werkt prima, alleen de storage is slecht.

Gezien ik gebonden ben aan PHP is Gearman mijn beste optie, maar ik ben bang dat ik wellicht een goed ander alternatief over het hoofd zie. Ik zou mijn Storage van de queue in Memcache kunnen doen, ik wil alleen de queue veilig stellen dus is SQL een fijnere optie.

Zijn er mensen die met Job Queue Servers werken met PHP projecten ?

[Wolfboy]

Ik moet zeggend at ik geen ervaring met BeansMQ of Gearman heb. Maar ik heb in ieder geval een RabbitMQ in productie en een 0MQ systeem in productie gehad

Persoonlijk kan ik RabbitMQ dan ook zeker aanraden, extreem stabiel en werkt best fijn. Maar ik denk dat het nogal van de rest van je stack afhangt. Persoonlijk draai ik een RabbitMQ systeem met rond de ~5M messages per dag in combinatie met Celery. Maar aangezien Celery in Python geschreven is kan het natuurlijk dat je dat liever niet aan je stack wil toevoegen.

Naar wat ik gehoord heb is Gearman voor PHP wel een prettige optie, maar daar kan ik helaas weinig over zeggen.

RabbitMQ kan ik in ieder geval zeker aanraden

[ACM]

Verwijderd schreef op donderdag 20 oktober 2011 @ 19:44:
Hier zijn een aantal goede pakketten voor, welke het beste eruit komen zijn:

- Gearman
- BeansMQ
- Rabbit

Om welke redenen zijn dit de beste?

Apache MQ

Je bedoelt Apache ActiveMQ? Tweakers.net draait daar al jaren mee (blijkbaar heeft ie sinds zijn start alweer 495.826.546 queued messages verwerkt), zowel via het STOMP-protocol als via JMS. Toen ik het destijds vergeleek met 'de rest' was het naast meestal sneller, ook fijner om mee te werken (in de zin dat je een duidelijker voor queue's bedoeld protocol gebruikt, STOMP) en zijn de persistence- en feedbackmogelijkheden erg goed geregeld. Bovendien kan je er - dit heb ik nog niet in de praktijk toegepast - vrij eenvoudig uitgebreide clusters van maken, mocht dat nodig zijn.
ActiveMQ is trouwens ook geforked naar een speciale geoptimaliseerde versie genaamd Apollo.

Maar het is niet echt een job-management systeem, uitsluitend een messaging broker voor queues en topics.

Ik ben aan de slag gegaan met Gearman, de reden hiervoor is dat dit een echte Queue server is voor jobs en de andere servers meer gebaseerd zijn op message servers. Opzich hetzelfde doel maar dan net wat anders.

Het is zelfs vooral een jobsysteem en queues is daar een onderdeel van, toch? Vziw kan je dmv JMS/STOMP ook communiceren dat je een reactie terug verwacht en daar dus ook op wachten - jouw synchroon wens - maar ook dat heb ik zelf nooit getest.

Een nadeel waar ik tegenaan loop is persistence storage voor de queue. Ik wil namelijk de status van de queue kunnen achterhalen omdat ik dat nodig heb,

Bij ActiveMQ kan je per bericht aangeven of het persistent of niet zou moeten zijn. Maar ongeacht de persistence kan je de status van de queues uitlezen. Daarnaast zou je berichten van de queue kunnen oppakken en vervolgens niet uitvoeren (geen acknowledge sturen), zodat ie daarna door een ander uitgevoerd kan worden. Omdat hier e.e.a. aan performance-optimalisatie zit is dit uiteraard wel wat tricky als alles in de goede volgorde moet blijven gaan.

Gearman kan dit doormiddel van een Drizzle plugin, dit is een MySQL fork welke wel naar MySQL servers kan praten.

ActiveMQ kan naast zijn eigen Kaha-store ook met MySQL en dergelijke werken. Maar als je puur de status van de queue wilt kunnen bekijken en/of berichten domweg niet kwijt wilt raken hoef je dat niet toe te passen.

Gezien ik gebonden ben aan PHP is Gearman mijn beste optie, maar ik ben bang dat ik wellicht een goed ander alternatief over het hoofd zie.

Elke message queue die met STOMP werkt of het memcache-protocol kan in principe gebruikt worden in php. De eerste is een tekstonly protocol waar een paar klassen voor bestaan. De laatste heb je vast al de module voor geinstalleerd, nadeel van memcache-protocol dat het hier niet echt voor bedoeld is.

Ik zou mijn Storage van de queue in Memcache kunnen doen, ik wil alleen de queue veilig stellen dus is SQL een fijnere optie.

Memcache is geen storage. Er is geen enkele garantie dat de records blijven bestaan, zelfs niet als je ruim voldoende geheugen alloceerd. Je zou natuurlijk wel een van de vele nosql-storage-oplossingen kunnen gebruiken, bijvoorbeeld membase (die spreekt ook memcache-protocol).

Zijn er mensen die met Job Queue Servers werken met PHP projecten ?

Job Queue Servers zelf nog niet, maar wel goede ervaring met ActiveMQ als "Queue Server" (aka Message Broker). Je zou kunnen kijken of er een project is dat e.e.a. regelt via een stomp-enabled message broker en dan kan je naar eigen keuze een willekeurige message broker er tussen hangen.

[ Voor 4% gewijzigd door ACM op 21-10-2011 08:00 ]

[Verwijderd]

ACM, dank je voor je lange reactie.

Het probleem is voor veel message-servers dat ze niet echt voor jobs geschikt zijn, het zijn en blijven message-servers.


Het lijstje wat ik gaf als zijnde "beste" alternatieven komt omdat jobs in die message-servers "makkelijkers" te runnen zijn. Ik heb zelf even door ApacheMQ heen gelopen maar het lijkt erop dat deze toch geschikt voor messages en jobs niet echt alles is.

Ik denk alleen dat Gearman met één ontwikkelaar niet echt levensvatbaar is... dus... issue indeed!

[Tieske[82]]

Ik ben op dit moment Gearman aan het gebruiken, en heb wat tests afgerond. Het werkt vrij eenvoudig vind ik zelf, maar het is me nog niet gelukt goed inzicht te krijgen in de queue status etc. Als je daar nog tips voor hebt? Verder is het mij niet bekend dat Gearman buggy zou zijn, heb je evt. links waar ik daar meer over te weten kan komen? De Gearman site zelf staat met name vol met success story's van niet al te kleine services namelijk..

[Verwijderd]

Gearman is inderdaad vrij eenvoudig en werkt prima.

Ik heb zelf ook een queue status nodig, dus wil ik dit via MySQL gaan doen. De Drizzle/MySQL implementatie zou wat buggy zijn:

https://launchpad.net/gearmand

[Verwijderd]

Ik heb eigenlijk altijd zelf iets customs gemaakt, omdat Gearman meestal overkill is voor simpele jobs als het versturen van emails of het periodiek afhandelen van een x aantal taken.

9 van de 10 keer kom ik uit bij een simpele daemon in python/perl die een database table / directory in de gaten houden en zo snel als er echt iets moet gebeuren sturen zijn andere scripts aan.

[Verwijderd]

Verwijderd schreef op vrijdag 04 november 2011 @ 15:03:
Ik heb eigenlijk altijd zelf iets customs gemaakt, omdat Gearman meestal overkill is voor simpele jobs als het versturen van emails of het periodiek afhandelen van een x aantal taken.

9 van de 10 keer kom ik uit bij een simpele daemon in python/perl die een database table / directory in de gaten houden en zo snel als er echt iets moet gebeuren sturen zijn andere scripts aan.

Ja dat heb ik ook het liefst, maar ik denk dat mijn xxx.xxx jobs per dag een eigen jobserver toch flink gaan irriteren....

[xzaz]

Verwijderd schreef op vrijdag 04 november 2011 @ 15:25:
[...]


Ja dat heb ik ook het liefst, maar ik denk dat mijn xxx.xxx jobs per dag een eigen jobserver toch flink gaan irriteren....

Waarom? Goed letten op de concurrency viewpoint. 999.999 zijn 'maar' 694 jobs per minuut, 11 per seconde.

[Wolfboy]

Aan de andere kant, waarom zou je het zelf bouwen als hier al prima technologieen beschikbaar voor zijn?

In veel gevallen kan je alles gewoon event based krijgen waar nodig.

[djc]

Als je zelf iets bouwt is ZeroMQ wel heel relaxed om het mee te bouwen. Neemt je heel veel werk uit handen en helpt om de communicatie tussen je processen te verduidelijken.