App seems slow when emailing

i’ve got an app that works well until actions that send email are
used. it seems that the user is having to wait for rails to send the
email before they get to the next page.

is there an easy way to move on to the next action or page while the
email is still trying to send?

Josh wrote:

i’ve got an app that works well until actions that send email are
used. it seems that the user is having to wait for rails to send the
email before they get to the next page.

is there an easy way to move on to the next action or page while the
email is still trying to send?

Unless the email in question is really huge, you can make this fast with
a local SMTP server which would be in charge of relaying the email. Use
SMTP for delivery and not sendmail when configuring ActionMailer. This
actually makes a big difference on small emails on my setup.

If the email is huge, you might use BackgrounDRb to handle the process.

Lionel

unfortunately i am using an external smtp server. currently there’s
not much i can do about that. i didn’t know about backgrounddrb
though. looks really cool, so hopefully that’s what i need.

On Jun 26, 8:39 am, Lionel B. [email protected]

Hey Josh,

Another option is to use activemessaging - like backgrounDRb it lets you
do
things asynchronously so your controller can return, but rather than a
process model, it is a messaging model.

http://code.google.com/p/activemessaging/

I know several people using this for doing email notifications
(including
me) - e.g. some event occurs, controller pushes a message on a queue,
then a
processor asynchronously pops off this message and spends whatever time
is
necessary to handle it and send out a bunch of emails to ‘subscribers’.

Cheers,

-Andrew K.
http://www.beginsinwonder.com

On 6/26/07, Josh [email protected] wrote:

used. it seems that the user is having to wait for rails to send the
If the email is huge, you might use BackgrounDRb to handle the process.

Lionel


Andrew K.

For a simpler solution you might just create a table to hold events
that need to be processed by an outside application. Message queues
are great but for something like sending email messages you also need
some way to track event failures and retry at a later time. Which
means you would need a separate table to do that on top of the message
queue. For a larger system I’d probably use a queue and have the
event processing on a completely separate server with it’s own
database, but that’s probably overkill for most applications.

Chris