14 Messages an Hour?

Hi All,

I just rediscovered PHPlist after many years and installed in on an intranet server for testing. I am currently processing messages at a rate of 14 an hour which is obviously painfully slow. I searched the forum but found nothing close to this. I am currently sending to two users. One message took 6 min.

I am running it on Ubuntu 16.04/Apache2.4/PHP 7.0/Sendmail 8?

Thanks in advance

So I switched to SMTP and the messages go out immediately. I would prefer however in this environment to not do that and use the default send protocol.

I have tried adding additional DHCP servers to the linux box but honestly can’t think of or find much more than that.

Anyone?

Nothing in five days? Is anyone out there?

@Corrigun If you are not sending through an smtp server then you are using the php mail() function.

You need to track down why that is so slow, it does not appear to be caused by phplist if sending through smtp does perform well.

Normally I would agree but I have other applications running on this server that send php mail without trouble. Joomla and Time Tracker for example. It seems to be just phpList that does not behave.

@Corrigun What are the batch and throttle settings in the config file? Are you sending using a cron job (recommended) or using the process queue command in the browser?

Batch-
define(‘MAX_PROCESS_MESSAGE’, 999);
define(‘MAILQUEUE_BATCH_SIZE’, 0);
define(‘MAILQUEUE_BATCH_PERIOD’, 3600);

Throttle-
define(‘MAILQUEUE_THROTTLE’, 0);
define(‘MAILQUEUE_AUTOTHROTTLE’, 0);

Max Process-
define(‘MAX_PROCESSQUEUE_TIME’, 0);

I am not using a cron job to send two E-mails. If I need to setup a cron job for two E-mails then I need to use something else.

Whereabouts did you see this time reported? phplist will send as fast as it can, so any delay is going to be elsewhere. The php mail() function invokes sendmail (you can see the actual command in phpinfo) so maybe looking at the logs of the mail server might be a start.

I forget exactly where but I think it was the summary after the batch was sent. Since I was one of the two recipients I can confirm it did actually take this long or longer.

I have not looked at the mail logs and I will however as I said before I have two other apps running on this same box that do not have this problem using this same protocol. The only conclusion I can reach is that it is this application and not the mail server.