Reply To: slow calculate_totals() – tips?

[Pablo]

Man this is tough. You’re right in saying that 100ms is just not right, and your numbers made me rethink all assumptions. I couldn’t get a further drilldown of that particular trace i initially showed, but you were right in thinking there’s other stuff happening triggered by ECF. I use the abandoned carts plugin, and it does its thing (reads and writes from its table) upon every cart change. It considers ECF’s resetting of autocoupons as cart changes. I have a discussion with that plugin’s writer similar to ours, in which he’s looking into using less frequently fired hooks. In the meanwhile i’ve come up with a hack for that plugin, to throttle its execution: that helped a bit.

There’s also code of mine that was running too often. I’ve applied a throttling technique to it similar to your add_action_once wrapper, and that helped a bit.

There’s code of mine hooked into woocommerce_product_get_price that runs all the time, but it is unavoiadable. It’s simple in its nature, but essential for our business rules: it checks for a session variable and then overwrites the price with a different one that’s saved in product meta’s, should the condition be true.

I’ve experimented with object cache via redis, that also helped a bit.

Oh! One of the things that does give ECF a hard time is my somewhat modified version of the popular woocommerce_maybe_add_multiple_products_to_cart hack. We don’t add products each at a time, we do it in bulk when the user presses a button. This gives a snappier UX, but kills the backend because once the bulk request is submitted we have to go through woo’s native add_to_cart for each of them, which triggers ECF reprocessing for each product.

As for the database, it’s a cloud db instance – different/dedicated server but on the same private network. It’s on a bulky rig with 16gb of ram.

You know – i also appreciate you calling out the instantiation of WC_Coupon. I think there’s a problem there.
We have 4 autocoupons, but they’re frequently applied and we have around 1k daily orders. This means that that darned “_used_by” prop is HUGE for them, and getting bigger by the minute. I hate that prop with a passion lol.

I apologize for going quiet. I’ve looked at so many things. Not to mention infrastructure stuff like changing from apache to nginx, tweaking fpm and opcache.

It’s been hard to sit down and write back. Every time i started to i was like “hmmm but i haven’t checked x yet, let me do that first”.

And i appreciate your patch! So much. I’ll definitely take it for a spin. It might just take me a little while to write back, but the quest continues.