The sending volume often exceeds 100%, can this bug be fixed
- Thread starter phanchin
- Start date
Hi,
The campaign wasn't over-sent but in fact, it was just the counter that is showing a bigger number. It was because of the batch size. When you have a batch size set, Mumara first increments the batch size and then push the emails to the MTA. If your campaign system-pauses during the send-out, the batch size gets incremented into the sent counter, however, it's not actually sent. Mumara fixes the counter itself upon the completion of the campaign or if you just pause/resume. In such a case if you want to see the actual counter, you can navigate to the broadcast stats and see the correct counter under the logs tab.
The campaign wasn't over-sent but in fact, it was just the counter that is showing a bigger number. It was because of the batch size. When you have a batch size set, Mumara first increments the batch size and then push the emails to the MTA. If your campaign system-pauses during the send-out, the batch size gets incremented into the sent counter, however, it's not actually sent. Mumara fixes the counter itself upon the completion of the campaign or if you just pause/resume. In such a case if you want to see the actual counter, you can navigate to the broadcast stats and see the correct counter under the logs tab.
To circumvent this issue, I will suggest you can use the loop method instead of batches when scheduling a campaign. With the batch method Mumara first increase the counter and then start sending email to send email faster. which shows the counter is more than 100%. However, this ambiguity is already reported to the dev team.
It's not the actual number that you are seeing. The actual number can be seen in the broadcast statistics under the Logs tab. The count on the "View Scheduled Page" increments at the start of batches and when you have continuous disconnection during the campaign, the number goes higher. But this number automatically gets fixed once the campaign is 100% complete in actual.
Certainly, to ensure efficient processing, we utilize batches. However, if you're encountering persistent issues with your sending nodes, you can opt for an alternative approach. You can either set the batch size to 1 (essentially no batch) or employ the loop method until the sending nodes are stable.
For instance, when scheduling a campaign with a batch size of 1000, Mumara avoids performing additional MySQL operations until all 1000 emails have been sent, optimizing speed. This means that the counter increments to 1000 before sending even the first email. If your connection experiences a disruption after sending 10 emails, you may notice an apparent increment of 990. Rest assured, the counter will be corrected upon completion of the campaign. This design is intentional to maximize the benefits of batch processing.
For instance, when scheduling a campaign with a batch size of 1000, Mumara avoids performing additional MySQL operations until all 1000 emails have been sent, optimizing speed. This means that the counter increments to 1000 before sending even the first email. If your connection experiences a disruption after sending 10 emails, you may notice an apparent increment of 990. Rest assured, the counter will be corrected upon completion of the campaign. This design is intentional to maximize the benefits of batch processing.
