It makes sense to allow the user to continue
working, even if the server is still trying to send email in the background. One option
is to simply fork off a separate OS process, or use a separate interpreter thread (via
Thread.new with a block) to send email asynchronously. However, this solution does
not scale well, as you must handle any concurrency issues that arise on your own. In
addition, you have overhead from starting a new thread or process on each piece of
mail. For high-volume mail situations, you want a mailer daemon running a tight
loop that can send mail without having to start a worker process.
The scalable option is the Robot Co-op??™s ar_mailer.* This little library uses the database
as an outgoing mail spool. When mail is to be sent, rather than delivering it
externally, Rails just dumps it into the database. The separate ar_sendmail process
picks it up and sends it along. This way, the application does not get backed up
because of slow SMTPperformance. ar_sendmail can be run periodically (from cron)
or continuously, as a daemon.
Further Reading
Zed Shaw??™s most famous rant, Programmers Need To Learn Statistics Or I Will Kill
Them All (http://www.zedshaw.com/rants/programmer_stats.html), is an excellent (if a
little aggressive) description of the most common misconceptions surrounding performance
measurement.
Peepcode has a screencast on benchmarking with httperf at http://peepcode.
Pages:
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287