> 7. NEVER send emails directly from web page code
Sending emails is slow. Incredibly slow. Don't tie up a precious web front-end process with doing so. Use a message queue instead.
Well. MTAs are message queues. Why use a third party software speaking a third-party protocol, adding more complexity only to eventually be talking SMTP anyways. As such, my message queue is a locally installed MTA listening on port 587, talking SMTP.
This is as fast or faster than any message queuing system you can come up with, but as it's managed by the OS, it's bound to work much better than third-party solutions.
I also get a lot for free in exchange. Stuff like automatic resending, queueing, queue management and so on.
As such, I would not strictly agree with point 7 in the article. Sure - don't send mail by talking to a remote MTA, but if it's running inside of your local network, using any other queuing system provides nothing but overhead.
Furthermore:
>How do you set up Nginx so that it won't die or kill your server when you receive a big burst of traffic? You install it.
No. You are shifting the burden of correct app server configuration from apache to php-fpm or whatever other process manager you're using.
In the end it doesn't matter much whether you're down completely (misconfigured apache) or still somewhat capable of serving static files while unable to serve any dynamic pages (misconfigured php-fpm).
Well. MTAs are message queues. Why use a third party software speaking a third-party protocol, adding more complexity only to eventually be talking SMTP anyways. As such, my message queue is a locally installed MTA listening on port 587, talking SMTP.
This is as fast or faster than any message queuing system you can come up with, but as it's managed by the OS, it's bound to work much better than third-party solutions.
I also get a lot for free in exchange. Stuff like automatic resending, queueing, queue management and so on.
As such, I would not strictly agree with point 7 in the article. Sure - don't send mail by talking to a remote MTA, but if it's running inside of your local network, using any other queuing system provides nothing but overhead.
Furthermore:
>How do you set up Nginx so that it won't die or kill your server when you receive a big burst of traffic? You install it.
No. You are shifting the burden of correct app server configuration from apache to php-fpm or whatever other process manager you're using.
In the end it doesn't matter much whether you're down completely (misconfigured apache) or still somewhat capable of serving static files while unable to serve any dynamic pages (misconfigured php-fpm).