Understanding the use case for this

[JoeMurray]

I'm trying to understand the use case for this a bit better. Let's say we have group with 100k contacts in it that we want to mail. There is in civicrm core an option to set the job size for each set of emails to be mailed. These jobs get queued up all at once when the mailing is started, and then dequeued and processed over time as cron jobs process each 'job'. There is a default number of emails in a job, which is set to 2500 on one of our instances.

I believe this use of a queue of jobs or a specific size that are processed separately when sending outbound mail helps to limited in the amount of work civimail does before completing each cron.

What is the advantage of, or role for, the split group extension in this context? Is it intended to provide a user level way of controlling these job sizes? One of our team implemented this on a site with about 75k contacts and 460k records in the group contact cache, and we continue to have a variety of problems. I'm trying to understand how this extension might be helping or hindering our performance and stability problems.

[JohnFF]

Hi Joe,

This extension allows for much more granular control, as you said. It also allows for split testing (e.g. of sending at different times - important for SMS messaging). We found a number of instances where large, unwieldy groups were better to split into different groups, including work allocation.

Without knowing more details about the problems you're facing I can't really comment. This is a very simple, small extension though. I doubt it'll be causing problems.

Thanks,