Hat jemand den Overhead der verschiedenen Hintergrundverarbeitungstechniken verglichen?
Hintergrund / RB, Starling, Workling MemcacheQ Bohnenstange Hintergrundjob (Bj) delayed_job (Dj)
Ich werde eines von ihnen auf einem Stück implementieren und möchte wissen, wie viel Speicher sie aufnehmen, damit ich es in meine Entscheidungen einbeziehen kann.
Es wird abhängig von Ihrer Rails-Anwendung selbst variieren.
Die meisten dieser Prozessoren hängen davon ab, dass Ihre Rails-Objekte im Wesentlichen die gesamte Rails-Instanz in den Speicher laden. Ihr App-Speicher hängt von der Anzahl der Modelle, der Auswirkung von Plugins und den vorherrschenden klimatischen Bedingungen Ihrer Umgebung ab.
Ich hatte ein 256mb Slice, auf dem mehrere Mongrels und BackgroundRB laufen, und stellte fest, dass der Hintergrundprozess ungefähr denselben Speicher wie eine Mongrel-Instanz verwendete.
Eine Option, die mir immer gefallen hat, ist, Ihre geplante Logik in einen Controller zu setzen und über Cron mit wget oder Curl aufzurufen. Sie können die vorhandene Rails-Anwendung nutzen und es ist sehr wenig Aufwand für die Einrichtung. Der einzige Grund, warum ich im obigen Fall nicht mit dieser Option gegangen bin, war eine Anforderung, alle 5 Sekunden in die Warteschlange zu gehen (Cron kann nur jede Minute laufen).
Ich wäre auch an einem umfassenden Vergleich interessiert, aber eine Sache, die ich sagen kann, ist, dass BackgroundRB vom Autor als veraltet betrachtet wird. Bei EngineYard empfehlen sie speziell BackgroundJob, nachdem sie hartnäckige Probleme mit BackgroundRB hatten. Ich habe jedoch nichts über die anderen Optionen gehört, die du erwähnt hast.
Für geringe Wartung mag ich Hintergrundjob. Es läuft in Ihrem Rails-Prozess oder über Cron, so dass keine Daemon-Prozesse überwacht werden müssen. Auf meinem Server verwendet Bj derzeit 35636 RSS (etwa ein Rails-Prozess wert).
Ich bin immer wieder überrascht, wenn ich von Leuten höre, die BackgrounDRB benutzen, weil es im Prinzip nicht gepflegt wird.
Tags und Links ruby-on-rails