arniesmtpbufferserver VS Que

My guess is that many people are implementing queuing mechanisms just for sending email.

The Linux file system makes a perfectly good basis for a message queue since file moves are atomic.

You can see how this works in Arnie SMTP buffer server, a super simple queue just for emails, no database at all, just the file system.

https://github.com/bootrino/arniesmtpbufferserver

A practical applications of atomic mv is building simple file based queuing mechanisms.

For example I wrote this SMTP buffer server which moves things to different directories as a simple form of message queue.

https://github.com/bootrino/arniesmtpbufferserver

Caveat I think this needs examination from the perspective of fsync - i.e. I suspect the code should be fsyncing at certain points but not sure.

I actually wrote (in Rust) a simple file based message queue using atomic mv. It instantly maxed out the SSD performance at about 30,000 messages/second.

Yeah I was using Celery for sending emails - nothing else.

And it was such a nightmare to configure and debug and such overkill for email buffering that in a fit of frustration I wrote the Arnie SMTP buffering server and ditched Celery.

https://github.com/bootrino/arniesmtpbufferserver

It's only 100 lines of code:

https://github.com/bootrino/arniesmtpbufferserver/blob/maste...

Here's the 100 lines of code:

https://github.com/bootrino/arniesmtpbufferserver/blob/master/arniesmtpbufferserver.py

Here's the github repo:

https://github.com/bootrino/arniesmtpbufferserver

It's MIT licensed.

Arnie is a server that has the single purpose of buffering outbound SMTP emails.

A typical web SAAS needs to send emails such as signup/signin/forgot password etc.

The web page code itself should not directly write this to an SMTP server. Instead they should be decoupled. There's a few reasons for this. One is, if there is an error in sending the email, then the whole thing simply falls over if that send was executed by the web page code - there's no chance to resend because the web request has completed. Also, execution of an SMTP request by a web page slows the response time down of that page, whilst the code goes through the process of connecting to the server and sending the email. So when you send SMTP email from your web application, the most performant and safest way to do it is to buffer them for sending. The buffering server will then queue them and send them and handle things like retries if the target SMTP server is down or throttled.

There's a few ways to solve this problem - you can set up a local email server and configure it for relaying. Or in the Python world people often use Celery. Complexity is the down side of using either Celery or an email server configured for relaying - both of these solutions have many more features than needed and can be complex to configure/run/troubleshoot.

Arnie is intended for small scale usage - for example a typical web server for a simple SAAS application. Large scale email traffic would require parallel sends to the SMTP server.

Arnie sequentially sends emails - it does not attempt to send email to the SMTP server in parallel. It probably could do fairly easily by spawning email send tasks, but SMTP parallelisation was not the goal in writing Arnie.

> Can you define "low throughput"?

<1000 messages per minute

Not saying SKIP LOCKED can't work with that many. But you'll probably want to do something better.

FWIW, Que uses advisory locks [1]

[1] https://github.com/que-rb/que

Probably worth mentioning that aside from delayed_job there are at least two more modern alternatives backed by the DB: Que and good_job.

Good article. Sidekiq is a good, well respected too. However if you are starting out I would recommend not using it, and instead choosing a DB based queue system. We have great success with que, but there are others like good_job.

(not sure why this comment was dead, I vouched for it)

There are a lot of ways to implement a queue in an RDBMS and a lot of those ways are naive to locking behavior. That said, with PostgreSQL specifically, there are some techniques that result in an efficient queue without locking problems. The article doesn't really talk about their implementation so we can't know what they did, but one open source example is Que[1]. Que uses a combination of advisory locking rather than row-level locks and notification channels to great effect, as you can read in the README.

[1]: https://github.com/que-rb/que

https://github.com/que-rb/que

This one seems to be the most performant. By a lot too, from my understanding (haven't ran any benchmark myself, but the readme shows some good postgres knowledge)

Que seems like a good alternative if one doesn't want to use Reids. However, given that most apps need Redis (and have it within their infrastructure) nowadays, I still think that Sidekiq is the better option in the generic case.

Implementations that use advisory locks like https://github.com/que-rb/que are much more efficient (atleast when I last tested) and will easily reach 10k job/s on even very modest hardware.

There is a Go port of Que but you can also easily port it to any language you like. I have a currently non-OSS implementation in Rust that I might OSS someday when I have time to clean it up.

It’s also possible to use advisory locks to implement a job queue in Postgres. See e.g. Que[1]. Note there are a fair number of corner cases, so studying Que is wise if trying to implement something like this, as well as some (a bit older) elaboration[2].

We implemented a similar design to Que for a specific use case in our application that has a known low volume of jobs and for a variety of reasons benefits from this design over other solutions.

[1]: https://github.com/que-rb/que

Do also take into consideration que-scheduler (disclaimer, am author). It is built on top of the robust que async job system.