external smtp

madde

Beginner
Hi
I have a question about email sending speed !

I am using mumara classic and PMTA (6 rotating ip's) on a VPS:
CPU: 4 vCores
Ram 12 GB
Unlimited Bandwidth

It sends out as expected, about 50K emails/hour

However, If I use a external SMTP in Mumara ( also PMTA with 6 rotating ip's)
it sends out much slower... about 4k emails/hour
(both mail servers are warmed up)
I have pinged the external smtp server... and it looks fine

Is this a mumara setting or pmta setting that
has to be configured ?

Thanks!
 
@madde The feeding time of the packet and the traveling time of the packet are two different things involved in the cumulative speed. So it means after you have shifted PMTA to an external server, the packet/email is taking 15 times longer to travel from the Mumara server to the MTA server. Rest assured, you can send more than 50k/hour using an internal network if the servers are placed within the same rack or even the same network.
 
Hi, I am struggling with the setup inside the software; i.e sending domains setup and I have installed the software on my smtp server. I was to to get off the ground and create lists and so forth.
 
@madde The feeding time of the packet and the traveling time of the packet are two different things involved in the cumulative speed. So it means after you have shifted PMTA to an external server, the packet/email is taking 15 times longer to travel from the Mumara server to the MTA server. Rest assured, you can send more than 50k/hour using an internal network if the servers are placed within the same rack or even the same network.

Thank you very much ! :-)
So, you are saying I can send more than 50k/hour with my server specs. ?! if so, how do that ?

Would you like to explain more about "using an internal network if the servers are placed within the same rack or even the same network"

Shall I go to : Intergration - pmta intergration - add Pmta server
instead of using external smtp ?

Thanks :-)
 
If the Mumara server and the MTA server are placed within the same rack, the traveling time of the packet will be minimum and you can save a huge delay. And yes, it depends again on your configuration i.e. how the MTA server is listening to the Mumara server. In some cases, the people make a common mistake that they don't interconnect them over the private network. If you have servers within the same rack and listening to them via a public network, it means the request is going to the DNS server and then going through all IP transit providers before coming to your MTA server. e.g. if you have your SMTP host set as smtp.yourdomain.com and the MTA server is placed next to the Mumara server, the packet is still traveling around the globe. So in such case, either you can use a private IP as the hostname or map smtp.yourdomain.com to a private IP in your server's host file, mostly location at /etc/hosts so before opening a public mapping, it will fetch the direct mapping from the host file.

Once done, it means you save the traveling time. Now second thing is to check if your server is well optimized to use maximum resources before upgrading to a costly server. In common cases, people usually upgrade the server when if their previous server wasn't being eaten fully by Mumara. e.g if you have PHP set to use memory, not above 2GB, it means upgrading from a 4GB server to an 8GB server will not make any difference to PHP. So you'll need to self calculate first and allocate memory to PHP and MySQL.

Then use multithreading to enhanced the speed and keep an eye on the server load in the terminal by using top or htop command. If the server is having no left resources, its the time to upgrade the server.

Also, I don't suggest using threads crazily. The best way is to perform a self check-up on multi-threads e.g. try using 2 threads and 5 threads and then 10 threads. The point where you find an increase in threads decreases the overall speed, that's your server's threshold limit. You can't make your server take a bite more than it can chew. So stay under the maximum resources available but utilize them fully.
 
I had the same problem, and I solved it by split the big list into some small lists, then creating multiple campaigns at once into smaller lists. You just try and gradually increase the number of campaigns and monitor the activity of both servers.
 
Back
Top