Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

can i send 100000 emails per day with this server? #324

Closed
infooer opened this issue Aug 16, 2017 · 14 comments
Closed

can i send 100000 emails per day with this server? #324

infooer opened this issue Aug 16, 2017 · 14 comments

Comments

@infooer
Copy link

infooer commented Aug 16, 2017

8G RAM
100G SSD
10Mbps
linux ubuntu 16.04
10 IPv4
10 domains

can i send 100000 emails per day with this server?
and anyone can recommend a VPS provider who can send large amounts of emails ?
thanks ~

@iammattmartin
Copy link

The amount of domains, IPs and OS are largely irrelevant.

You could be pushing the specs of the server, you may need to play with tuning the service to meet your requirements.

No recommendations but that amount is likely to generate some interest - it's a LOT of email but that question is probably outside of the scope of an "issue" with the software.

@infooer
Copy link
Author

infooer commented Aug 18, 2017

@mattmartincouk Thanks for your reply. I just want to know exactly what kind of configuration is good for running this software, and it would be better if you have the recommended VPS service provider

@catphish
Copy link
Contributor

This question has been asked a few times. The general answer is yes. Postal should have no trouble with 100,000+ emails per day on an 8GB host.

It may be necessary to tune a couple of things to maximize performance. Postal only runs one send worker by default. It should be possible to increase this to 4 workers with this much RAM. MySQL settings should also be optimized to get the best performance. The following tweaks are probably a good start:

max_connections = 1000
wait_timeout = 31536000
max_allowed_packet = 256M
innodb_buffer_pool_size = 1024M
innodb_flush_log_at_trx_commit = 2

I would be interested in numbers from anyone who has actually tested this. We run Postal with 8 workers on a host with 12GB of RAM and it has absolutely no trouble with our mail volume (approx 150k emails per day).

@catphish
Copy link
Contributor

nb. The number of IP addresses and number of domains should have no impact on performance. It should not be necessary to assign multiple IPs to a single host unless you are sending email for a number of different people and wish to ensure that SPAM sent by one does not negatively impact the reputation of the others.

@sahilsunesara
Copy link

sahilsunesara commented Sep 26, 2017

@catphish Could you please tell me which server hosting company are you using for 150K emails per day?
also please tell me how many IP Pool are you using?

Thanks

@spheron1
Copy link

aTech host their own servers and run their own network

@sahilsunesara
Copy link

Thank you. one more question i am using 8GB RAM and application running very very slow.. could you please tell me that will be the reason?

i also reinstalled VPS os as well as postal but during postal installation it's took more then 1 hours to install using quick installation command

what's wrong any idea ?

Thank you

@willpower232
Copy link
Collaborator

@sahilsunesara have you increased the workers and changed the MySQL settings as above?

Regarding the slowness, it might be that your servers network isn't very good and slowing down transfers or your server has a slow CPU or you are running other things on the server. It might be worth testing another provider to see what the difference is.

If you keep experiencing problems, you should open a new issue with information of everything you have tried.

@pjv
Copy link

pjv commented Aug 4, 2019

In case this is useful to anyone else looking for specific numbers, I am currently running a postal server on a 4GB VPS with the following (partial) configs:

/opt/postal/config/postal.yml

workers:
  quantity: 4
  threads: 4

/etc/mysql/my.cnf

[mysqld]
innodb_buffer_pool_size = 512M
max_connections = 500
wait_timeout = 31536000
max_allowed_packet = 256M
innodb_flush_log_at_trx_commit = 2

It's been working fine in testing as a transactional email sender for a few web apps for the past few weeks, sending out just a few hundred emails a day.

Yesterday I did the first stress test of this server, sending out a newsletter mailing to ~32K subscribers. To get a sense of capacity, I set the web app that was doing the mailing to push 300 emails per minute to Postal (via SMTP). It had no trouble keeping up and getting the emails sent. Based on watching logs as the mailing went through, I could see that Postal with the above config could have handled a higher load, so next time I'll try pushing 600/minute and keep increasing until I find limits.

Even at 300/minute though, Postal already out-performed @SparkPost for sending to this subscriber list via our web app and replacing SparkPost (who recently decided to renege on an "unequivocal" promise made by their CEO in 2016 to maintain a specific free tier level for the life of any then-existing accounts) was my primary motive for standing up this Postal server, so I'm very pleased.

@catphish
Copy link
Contributor

catphish commented Aug 4, 2019

Thanks for the update. That's great news. High volume performance was not a priority for us, but at the same time we certainly aim to make it as efficient as possible (as we do send a lot of transactional email!), so it's great to hear that it's scaling well. To an extent, performance will depend on the recipients. Sending lots of emails to the same destination ISP will usually be a lot faster than sending to lots of different recipient ISPs (because connections can be reused). Similarly, it will of course be faster to send to faster (or nearer) recipient servers, those that respond slowly will mean a worker can't be used for anything else. Beyond that, the main limitation is the number of send processes, each one will deal with one remote server at a time, and whether the database can keep up.

@michaelsomerville
Copy link

In case this is useful to anyone else looking for specific numbers, I am currently running a postal server on a 4GB VPS with the following (partial) configs:

/opt/postal/config/postal.yml

workers:
  quantity: 4
  threads: 4

/etc/mysql/my.cnf

[mysqld]
innodb_buffer_pool_size = 512M
max_connections = 500
wait_timeout = 31536000
max_allowed_packet = 256M
innodb_flush_log_at_trx_commit = 2

It's been working fine in testing as a transactional email sender for a few web apps for the past few weeks, sending out just a few hundred emails a day.

Yesterday I did the first stress test of this server, sending out a newsletter mailing to ~32K subscribers. To get a sense of capacity, I set the web app that was doing the mailing to push 300 emails per minute to Postal (via SMTP). It had no trouble keeping up and getting the emails sent. Based on watching logs as the mailing went through, I could see that Postal with the above config could have handled a higher load, so next time I'll try pushing 600/minute and keep increasing until I find limits.

Even at 300/minute though, Postal already out-performed @SparkPost for sending to this subscriber list via our web app and replacing SparkPost (who recently decided to renege on an "unequivocal" promise made by their CEO in 2016 to maintain a specific free tier level for the life of any then-existing accounts) was my primary motive for standing up this Postal server, so I'm very pleased.

Workers doesn't seem to be in the file these days. Did you add it ?

@pjv
Copy link

pjv commented Nov 18, 2021

@navinp
Copy link

navinp commented Jun 2, 2022

Hello, hope you are still around here:
how long does it take with these specs for emails to get delivered to user inbox?

I was hoping to find a way to make the email delivery 1 second or less than 1 second.

@lenny1150
Copy link

I'm a newbie ... how can I update the database? What is the command for that.... please help

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants