postal 3.1.1/3.2.2 drastically dropped email sending rate #2886
Replies: 2 comments 15 replies
-
You'd need to look at your logs and look at load on your system to see which components might be under load. Just adding workers to a machine that doesn't have the necessary memory and CPU to support it might also be counterproductive. |
Beta Was this translation helpful? Give feedback.
-
One thing might be useful is to run the following query on the database of your mail server. It'll show the average latency for dequeueing for all messages over the last hour. You can look over longer period of time by changing 3600. The "message rate" metric shown in the web UI isn't all that useful for determining system performance. I will adding this information to the web UI soon. SELECT
AVG(latency) AS average_latency
FROM
(
SELECT
messages.id,
COALESCE(MIN(deliveries.timestamp), UNIX_TIMESTAMP(NOW())) - messages.timestamp AS latency
FROM
messages
LEFT JOIN
deliveries ON messages.id = deliveries.message_id
WHERE
messages.timestamp >= UNIX_TIMESTAMP(NOW()) - 3600
GROUP BY
messages.id
) AS subquery; |
Beta Was this translation helpful? Give feedback.
-
My database is as good as it was working with 70 emails/minutes. I just did the postal upgrade to version 3.1.1 and the sending rate went down to 6-8/minutes. I tried upgrading it to 3.2.2 but no luck.
No matter how many workers I add, it doesn't increase. On 2.3.3, it was sending 70/minutes with 4 workers, as soon as I upgraded to 3.1.1/3.2.2 it doesn't even go above 8/minute with 16 workers.
Could someone please help me with this?
Beta Was this translation helpful? Give feedback.
All reactions