Performance regression in API3 related to campaign_id parameter
We found a performance regression related to API3 calls using the campaign_id
parameter. It was introduced in 5.36 with this. A particular workload we have (batching in CiviSEPA, which creates a few thousand contributions) went from 31 minutes to 116 minutes. This is probably due to the fact that campaign_id
was previously treated as a PseudoConstant with caching, but is now loaded for every call to _civicrm_api3_validate_integer
for campaign_id
. This tends to get called a lot for us.
The issue probably only affect sites with a significant number of campaigns (>3k in our case) that create lots of entities linking to those campaigns using API3, so I'm not sure if there's interest in fixing this.
We went with a simple hack where we only bother loading campaign names if the parameter is not an integer as integers are what our batch processes tend to use (though we do have other code where we pass in campaign names, so the original fix is definitely appreciated and necessary
We could introduce caching somewhere in that code path, but I don't think there's much precedent for doing that on the API3 level and it feels a bit like I'd be opening the door to cache invalidation hell.