Sendout batches don't complete and plugin is very slow

[ghost]

Steps to reproduce.

Slow CP in general, even when not sending anything out

1. Browse the Craft CP. Clicking any page is snappy as usual.
2. Click Campaign -> Sendouts and everything slows to a crawl
   2.1) Server I/O usage (capped at 3mb) maxes out at 100%. but returns to a negligible level when the sendout finally opens

Sendouts are incomplete

• I've configured Campaign as follows 'maxBatchSize' => 200, and 'batchJobDelay' => 7200, so 200 emails every two hrs.
• I'm trying to send to a list of about 8k
• Sendout batches manage to send to maybe 50-ish, then just stop.

See video for this in real time, server stats and I/O usage
https://drive.google.com/open?id=16-S6LhQOmrogneNn470qzTpNZJtqCfjm

Can I troubleshoot any of this somewhere? Is there an error log I can look at?

Thanks!

Edit

I've paused and resumed the sendout a few times during my testing of this problem, and looking at the db queue I see that a few jobs have bunched up (see attached image). Is that normal? The first job has a longer delay because I didn't change the campaign.php settings before starting the sendout.

[putyourlightson]

I've never seen the sendouts page load that slowly. Yes, the batches are each assigned to a new job. A few questions:

1. Is this a live or test server environment?
2. What is the memory limit for PHP on the server set to?
3. Is the sendout page always load to slow or only when sending?

[phoob]

I’ve seen it load somewhat slowly (noticeably more slow than other craft cp pages, but not this bad..) I thought maybe it could have something to do with using the craft async queue plugin, which runs jobs asynchronously, and can (I guess) be quite resource hungry..

[ghost]

Hey,

1. This is a server we use for staging, but it is identical in every way to the ones we use for production. Craft is set ENVIRONMENT="staging" if that matters at all
2. Memory limit is 1024M
3. I paused the sendout when I submitted this issue (it is still paused) and I tried loading the sendout page again now, and if there is a difference, i can't spot it (ie it's very slow, seems the same)

Edit
I just noticed that opening the actual sendout is noticeably faster when it is paused, so to be clear.
Going to Campaign > Sendouts is still as slow as shown in the video, and there are only two sendouts in existence. One was yesterday as a test to 5 recipients, and the other one is the one giving me the problems. But when I click on the name of the sendout where I can see its details, that page loads as fast as can be expected now that it is paused. Resuming it will cause that page too, to load very slowly.

[putyourlightson]

What could be happening is that while sending, a sendout is locking the database in order to keep track of sending progress. The strange thing is that you said you are only sending in batches of 200 with a delay.

Have you tried sending in the background? This is possible either by disabling runQueueAutomatically and using a cron job as documented here or by using the Async Queue plugin.

[ghost]

I will try that, but I suspect the problem is elsewhere.

Just did some more testing.

The I/O jumps to 100% even just by clicking on Campaign > Sendouts, as well as when clicking on Save and Preview on a sendout, so it doesn't appear related to actually sending emails?

[ghost]

I was able to setup the cron job as suggested, and trigger a sendout. It looks like only about 100 emails were sent though, so not sure what happened to the rest of the batch. Also, I/O jumped to 100%.

Now the sending is over, and this is strange, going to Campaign > Sendouts to list the 2 sendouts I have is reasonably fast all of a sudden, clicking on the my first test, the one I sent to 5 recipients and that is 100% complete, is also very fast to open. But cliking on the one in progress (but still waiting for the delay between batches), is super slow to open.

The only difference between them is that the slow one is attached to a list of 8 200 subscribers. Shooting blindly in the dark here, but is there some (bug) somehow that fetches each subscriber in the list attached to the sendout, and that's what's stalling it so much?

[ghost]

So Chrome devtools told me loading the sendout page (in this case campaign/sendouts/regular/10343) took 1.5 minutes. I then deleted all the logs from the server (site/storage/logs) and ran the test again. This time the page took just under 30 seconds to load, however the logs folder filled up again. Big.

Simply loading campaign/sendouts/regular/10343 produces 56.4MB worth of log files split into 6 different files. If loading the page is writing all that to disk, it must be related, no? The log files mention Campaign a lot.

Ben: I'm sending you the log files on Discord. I'm not entirely sure if there is sensitive info in there I shouldn't just post anywhere. Hope that's cool.

[putyourlightson]

Thanks for the detailed report @stianmandarin. I believe the delay has to do with the calculation of pending recipients and I'm working on optimising this which should help to resolve the issue. There is quite a bit of refactoring involved bu I expect to have this ready by early next week. Thanks for your patience!

[ghost]

Thanks for your excellent support @putyourlightson!

[putyourlightson]

@stianmandarin are you using any segments in the sendout that is being slow?

[putyourlightson]

Can you also check how many database queries are run when viewing the sendout page? Enabling the Craft debugging toolbar will show you cleary.

[ghost]

@putyourlightson Not using any segments.

db queries
Campaign > Sendouts: 99
Campaign > Sendouts > "Sendout name": 105

[ghost]

Even though the servers are identical, I will try putting the site up on one of the others to see if there's something wrong the the server itself. Will get back to you

[ghost]

@putyourlightson Alright, put it up on a different server, but it didn't help. Also, I tried disabling devMode which reduced the db q. to 67, but did not affect the speed in any way

[putyourlightson]

Ok, I think it's time I had a look at the server. Can you please send credentials to a staging server that is experiencing the issue to info@putyourlightson.net with a description of the steps to take to reproduce it? An admin account in the CMS and ftp details if possible too.

[ghost]

@putyourlightson Thanks! Will do!

[putyourlightson]

Also, how are you testing sending to such a large list without live email addresses?

[ghost]

@putyourlightson With my first test of 1 000 I sent to stian+1@mandarindesign.no and stian+2@mandarindesign.no etc etc

Will explain about the other list in the email, coming shortly

[putyourlightson]

Fixed in 1.5.2.