Comments on: Speeding up email delivery on Rails http://blog.wonsys.net/posts/27-speeding-up-email-delivery-on-rails/ Blogging about design, development, entrepreneurship, arts & culture and, of course, our products Tue, 06 Jan 2009 15:43:34 +0000 http://wordpress.org/?v=2.5.1 By: KinOfCain http://blog.wonsys.net/posts/27-speeding-up-email-delivery-on-rails/#comment-1595 KinOfCain Thu, 02 Oct 2008 00:25:11 +0000 http://blog.wonsys.net/posts/27-speeding-up-email-delivery-on-rails/#comment-1595 I think the -O option is ignored if you're using postfix, which most places are. (sendmail on modern distros is usually a compatibility layer, and postfix is the actual delivery agent), so this doesn't do much of anything. I think the -O option is ignored if you’re using postfix, which most places are. (sendmail on modern distros is usually a compatibility layer, and postfix is the actual delivery agent), so this doesn’t do much of anything.

]]> By: Michele http://blog.wonsys.net/posts/27-speeding-up-email-delivery-on-rails/#comment-222 Michele Sun, 21 Oct 2007 09:38:25 +0000 http://blog.wonsys.net/posts/27-speeding-up-email-delivery-on-rails/#comment-222 Actually, we aren't forking: we're using asynchronous sending, thus the email is added to Sendmail's own queue without having to wait for it to be delivered. The biggest problem I see is with error handling and maybe with scalability once you start sending thousands of email a minute, in which case you'd better set up a proper mail server, anyway. ;) Actually, we aren’t forking: we’re using asynchronous sending, thus the email is added to Sendmail’s own queue without having to wait for it to be delivered.

The biggest problem I see is with error handling and maybe with scalability once you start sending thousands of email a minute, in which case you’d better set up a proper mail server, anyway. ;)

]]> By: Federico Feroldi http://blog.wonsys.net/posts/27-speeding-up-email-delivery-on-rails/#comment-221 Federico Feroldi Sat, 20 Oct 2007 23:00:23 +0000 http://blog.wonsys.net/posts/27-speeding-up-email-delivery-on-rails/#comment-221 Actually I prefer the queue approach because it doesn't require a fork and is more scalable (you can have multiple delivery agents). To lower the delay you can make use of a message queue (like activemq, spread and many others) to notify the agents that a new message was added to the queue. Or, to make the things easy, you can make the agent listen to HTTP notifies coming from the sending process, so you can queue the message on the database and then notify the agent with an HTTP request. Actually I prefer the queue approach because it doesn’t require a fork and is more scalable (you can have multiple delivery agents).
To lower the delay you can make use of a message queue (like activemq, spread and many others) to notify the agents that a new message was added to the queue.
Or, to make the things easy, you can make the agent listen to HTTP notifies coming from the sending process, so you can queue the message on the database and then notify the agent with an HTTP request.

]]>