On Sat, Jan 1, 2011 at 3:38 PM, Ville Mattila <[email protected]> wrote:
> 1) Build a symfony2 console command that does all tasks and tie the
> command with a gearman worker process. In this way, whenever gearmand
> receives a task "finalize_registration", it feeds it to the Symfony2
> console via command line. However, this is pretty hard to maintain:
> when the amount of different tasks grow up, I need to start a worker
> for each of the task type and carefully plan which server hosts each
> of the task. Also, console commands are rather slow as the service
> container and other similar things are built for one run and then
> destroyed.
What you could have pretty easily imo is just one single gearman
console command. That way it's just one worker, but in your
->doBackground call you would not pass the worker name but rather the
command name to run. Gearman then would execute "app/console gearman
$commandname". Your gearman Command would just be a map of name to
service names.. i.e. send_registration_email maps to the registration
service, and method sendMail. That's fairly easy to maintain I'd say,
and should be flexible enough.
I wouldn't worry about the service container instanciation. That is
done anyway at every request, be it HTTP or CLI based. Anyway if
you're going for gearman, it's to gain in scalability, the loss of
speed for one unit of work doesn't matter as much imo, as long as you
can run it parallelized.
If you need various worker boxes doing different tasks, then you could
have a few different console tasks, one for email sending, one for
data crunching, etc. Then you'd do ->doBackground('email',
'send_registration') which would make the email gearman worker call
"app/console gearman:email send_registration".
> 2) Expose background tasks as regular routes that can be called via
> HTTP, for example www.example.com/tasks/finalize_registration. I would
> then tie a gearman worker with curl or wget, this could make an
> automatic HTTP call to the task uri. The benefit is to have all
> service containers ready, as well as the whole environment available
> easily - the finalize_registration task can easily refer to other
> services and the configuration can be the same in whole application.
> For balancing across the hosts, I can do it very easily. However, I do
> not see this very elegant solution and HTTP query has some overhead in
> itself also.
As I said above, I don't think you gain anything speed wise, and
you're just doing crazy hacks this way.. -1.
> 3) Build a symfony2 console command containing some implementation of
> http://php.net/manual/en/class.gearmanworker.php, with some
> intelligence deciding what tasks could be run... Well pretty good, but
> I still find some unnecessary overhead from the service container and
> I am not sure that this is good way to use console.
It could work, but not sure if you're not just doing work for nothing
vs approach 1.
Cheers
--
Jordi Boggiano
@seldaek :: http://seld.be/
--
If you want to report a vulnerability issue on symfony, please send it to
security at symfony-project.com
You received this message because you are subscribed to the Google
Groups "symfony users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-users?hl=en
