Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Filters for limiting async send queue batch size #237

Open
boonebgorges opened this issue May 11, 2023 · 0 comments
Open

Filters for limiting async send queue batch size #237

boonebgorges opened this issue May 11, 2023 · 0 comments
Milestone

Comments

@boonebgorges
Copy link
Owner

Related: #163

In its asynchronous send queue, BPGES attempts to determine the maximum sensible batch size by checking regularly for memory and time usage, and then ending a batch when 90% of either calculated maximum is reached. This is imperfect. In some hosting environments, it may not be possible to determine real memory use or the actual time/memory limits. And the 90% threshold assumes that the remaining 10% will be enough to complete execution, which will not necessarily be the case.

As such, there should be easy ways to reduce batch size. There are existing filters in place wp_bpges_send_queue_memory_exceeded etc that allow you to do this in certain ways. But the logic for doing so is hard, and in the case of time_exceeded there may not be enough information available in the filter callback to make an accurate calculation.

One or two new filters would be helpful here. I'm thinking two separate types of filters:

  • A batch_size filter. By default, it'd be null, which means that the value would be calculated on the fly, as is currently the case. If an integer is provided, it will be used in place of the memory/time checks.
  • A send_this_notification filter that would appear in the do loop. This would simply filter the value of $this->memory_exceeded() || $this->time_exceeded() (see eg
    if ( $this->time_exceeded() || $this->memory_exceeded() ) {
    ) so that a plugin could do its own on-the-fly determination of whether to continue, without using a workaround related to the existing memory_exceeded and time_exceeded filters.
@boonebgorges boonebgorges added this to the 4.1.0 milestone May 11, 2023
@boonebgorges boonebgorges modified the milestones: 4.1.0, 4.2.0 Aug 14, 2023
@boonebgorges boonebgorges modified the milestones: 4.2.0, 4.3.0 Oct 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant