On Fri, Aug 12, 2011 at 6:56 AM, Nick Knutov <mail@knutov.com> wrote:
Yes, in my case the load can be high and I still want to do some job after sending response.
For example, I need to send emails, and it can be done with cron scripts (with overhead on serialization), but I need to send emails as soon as possible after sending rendered page to upstream/browser.
I made this simple Dancer app that queues up emails on a job queue. It uses Net::Stomp as the client. https://github.com/ironcamel/postmail/blob/master/lib/Postmail.pm There is a separate worker script running that is processing and sending the emails: https://github.com/ironcamel/postmail/blob/master/bin/worker.pl I use POE::Component::MessageQueue (pocomq) as the message broker (queue server). It is all actually quite simple to set up. There are lots of other good messaging systems. Others have mentioned some good ones. For this sort of thing, I think you really should use some kind of job queue. It helps to decouple your application, and makes scaling very easy. I don't think Dancer needs some new fancy hook. This problem can easily be solved without that. All these new hooks in Dancer are making me nervous :) -Naveed
So, in my case, I can load more back-end instances and do it as described to save some seconds between sending response and sending emails.
12.08.2011 16:13, Flavio Poletti пишет:
On Fri, Aug 12, 2011 at 5:49 AM, Nick Knutov <mail@knutov.com <mailto:mail@knutov.com>> wrote:
I agree, forking is another way to do it, but as far as I know, it can lead to very high load. Also, dying process is a heavy operation, as far as I remember.
I don't fully understand the role of server load here.
On the one hand you want to perform those heavy operations inside your Dancer process after the page has been delivered. I would say that this is reasonable if the load on your server is very low, because you're asking your front-end infrastructure to take care of back-end duties as well.
On the other hand you're very concerned with load. If this is the case, are you sure that blocking your front-end process to carry out the back-end duties is the right way to go? You might shave off the fork penalties (but you have to do your benchmarking homework here, and probably with a reasonable copy-on-write handling you don't suffer that much), but this would be nothing compared to how stuck your front-ends would become.
If the load is your concern, you should decouple the frontend from the backend as much as possible. I'd suggest to serialize the relevant data in some way and push to a queue that is dealt with by some other process, which might even run on another machine if the load on a single server gets too high. If you need more, with proper sharding you could also reach full horizontal scalability.
Cheers,
Flavio.
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
-- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 _______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users