5

I send daily a newsletter to about 20K recipients. After moving to other server I need about six times more time to this using the same PHP scripts – I tried many different settings but had no luck with it (please see this post). The email server seems to be properly configured (with regard to spam, relay and viruses), the server runs with Plesk 11.5.30.

Doing many experiments, changing PHP scripts and Postfix settings I was able to achieve the best performance with the following:

  1. Sending emails from PHP using SwiftMailer.
  2. Using SMTP (local account) as transport.
  3. Dividing recipients list in four parts and starting separate PHP-CLI process for each one.

When I start only one process, PHP sends about 5 emails / second (which are about the same when I send emails using mail() function). Postfix has no problems with sending them "on the fly“ so there is almoust no queue.

When I start four processes, PHP sends about 10 emails / second, however postfix is no more able to send them „on the fly“ (it can send only about 5 emails / second) so the queue becomes bigger and bigger. When the PHP processes are over, I have about 4500 emails in my queue. And here comes the interesting part: when there are no more active PHP processes sending emails, Postfix „accelerates“ to sending about 20 emails / second. Would Postfix be able to send the emails at this rate while PHP is delivering new emails? there would be no queue and it would solve my problem.

I would appreciate any idea what could I do to improve the performance of my script and server sending the newsletter.

Here comes the Postfix configuration:

root@hostname:~# postconf -n 
alias_database = hash:/etc/aliases 
alias_maps = hash:/etc/aliases, hash:/var/spool/postfix/plesk/aliases 
append_dot_mydomain = no 
biff = no 
config_directory = /etc/postfix 
disable_vrfy_command = yes 
inet_interfaces = all 
inet_protocols = ipv4 
mailbox_size_limit = 0 
mailman_destination_recipient_limit = 1 
message_size_limit = 51200000 
mydestination = (none), localhost, localhost.localdomain, localhost 
mydomain = domain.com 
myhostname = myhostname.com 
mynetworks = 127.0.0.0/8 [::1]/128 my.ip.add.ress 
plesk_virtual_destination_recipient_limit = 1 
readme_directory = no 
recipient_delimiter = + 
relayhost = 
sender_dependent_default_transport_maps = hash:/var/spool/postfix/plesk/sdd_transport_maps 
smtp_connect_timeout = 10s 
smtp_helo_timeout = 100s 
smtp_send_xforward_command = yes 
smtp_tls_security_level = may 
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache 
smtp_use_tls = no 
smtpd_authorized_xforward_hosts = 127.0.0.0/8 [::1]/128 
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU) 
smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_rbl_client zen.spamhaus.org 
smtpd_proxy_timeout = 3600s 
smtpd_recipient_restrictions = permit_mynetworks, check_client_access pcre:/var/spool/postfix/plesk/no_relay.re, permit_sasl_authenticated, reject_unauth_destination 
smtpd_sasl_auth_enable = yes 
smtpd_sender_restrictions = check_sender_access hash:/var/spool/postfix/plesk/blacklists, permit_sasl_authenticated, check_client_access pcre:/var/spool/postfix/plesk/non_auth.re 
smtpd_timeout = 3600s 
smtpd_tls_cert_file = /etc/postfix/postfix_default.pem 
smtpd_tls_key_file = $smtpd_tls_cert_file 
smtpd_tls_security_level = may 
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache 
smtpd_use_tls = yes 
transport_maps = , hash:/var/spool/postfix/plesk/transport 
virtual_alias_maps = $virtual_maps, hash:/var/spool/postfix/plesk/virtual 
virtual_gid_maps = static:31 
virtual_mailbox_base = /var/qmail/mailnames 
virtual_mailbox_domains = $virtual_mailbox_maps, hash:/var/spool/postfix/plesk/virtual_domains 
virtual_mailbox_limit = 0 
virtual_mailbox_maps = , hash:/var/spool/postfix/plesk/vmailbox 
virtual_transport = plesk_virtual 
virtual_uid_maps = static:110
Community
  • 1
  • 1
Okizb
  • 99
  • 1
  • 15
  • If Postfix gets faster when your PHP processes have finished, maybe you have a CPU problem? What does `top` say when the PHP processes are running? Are you on a shared server or a VPS? What spec? – halfer Oct 30 '13 at 13:20
  • We use a dedicated server which actually does not have much to do. CPU and memory are not an issue - we have enough ressources (I checked this again today while we were sending our newsletter). Running iostat -m -x -d 5 I see there is very high disc usage (%util up to 100% - when PHP and Postfix are done it is about 10% - might this have something to do with our performance problems?) What I don't undrestand is, why is PHP on the new server able to send in one process maximum 5-7 mails / second (if you run only one process), while our old server was able to send 20 and more per second. – Okizb Oct 31 '13 at 14:18
  • I'm not an expert on server issues, but 100% of anything would be worth investigating further, certainly. Does it say which of PHP and Postfix are responsible for that level of usage? – halfer Oct 31 '13 at 15:11
  • PHP seems to be responsible for the high usage. What I really don't like is I have to start many processes. On the old server I started one process and PHP was able to "transport" about 20 mails / second to Postfix. So the question is what do I have to do accelerate PHP's sending mails rate. – Okizb Nov 04 '13 at 09:50
  • Nothing in mail log about 'unqualified host name' or 'failed name resolution'? Hard to diagnose with "what changed" when it sounds like everything did. – ficuscr Nov 05 '13 at 16:45
  • If you have 100% disk usages, both smtpd and qmgr are swamping the disk. Set in_flow_delay to try to slow down in incoming e-mails. http://www.postfix.org/postconf.5.html#in_flow_delay. Reason for difference in one servers verses another could be blacklist checking (sender restrictions) and DNS validation - check you have local DNS cache and not going external, use local blacklist if you can or turn off for locally sent emails (add "permit_mynetworks" in sender restrictions). – Robbie Nov 08 '13 at 03:19
  • Or you could spend <$150/m and outsource the sending to an email service provider, such as Mandrill and spend your time worrying about quality content instead of CPU's, uptime and deliverability – Mike Causer Nov 08 '13 at 11:21

3 Answers3

2

Since you write about your PHP process are sending about 5 or 20 mails per seconds, I'll suppose you are already measuring in detail your PHP code, so if this delay is in the PHP code you should be already discovered.

Reading the comments I also suppose your systems are quite big, so you have enough ram and disk.

In my experience a very common problem that could cause such kinds of delay are the DNS resolutions, well, I mean a wrong configuration of DNS, that leads in a delay all around. But this hypothesis is all to be proved.

On the other hand, I even remember that postfix have a throttling configuration in order to avoid server abuses. http://www.postfix.org/TUNING_README.html

At last, if you don't find anything in the postfix configuration, what I can suggest you is to try to debug the postfix process during its execution, with the utility strace.

It is a quite useful utility, I used it often when I have to debug non common problems. In short: strace lists all system calls done by the process. There are a lot of options available in strace, but I usually use only:

strace -fp <pid of main process>

During the debug you'll see all the system calls executed by postfix main process and all its children. If you add the -c option then you'll see the time spent for every system call.

freedev
  • 25,946
  • 8
  • 108
  • 125
0

Hey I cannot find the exact problem with your settings but I have read the comments which might help to find the exact time lag. Please refer http://ubuntuforums.org/showthread.php?t=2007309 and also you can recheck your code by http://liangsun.org/posts/configure-mail-service-with-php-mail-function-and-postfix/

And for settings of the swiftmailer refer https://bbs.archlinux.org/viewtopic.php?id=82062

Viswanath Polaki
  • 1,357
  • 1
  • 10
  • 19
0

Thank you for all your answers and your effort. Fortunatelly I was able to find the main cause of the problem - it was saving the queue on the hard disc. We changed it to RAM and are now able to send about 30 emails per second.

Okizb
  • 99
  • 1
  • 15