ATUM Multi-Inventory isn't scalable enough for us due to it being slow

Atrix

Hello, we're trying out your multi-inventory product some more to see if it's a good fit and we have a major concern.

I can load 27k products page in the admin in 3 seconds without multi-inventory enabled. But with it enabled it takes over 9 seconds. This is with caching mostly disabled but we're trying to keep our store fast. We've tested near 300k products with the exact same setup and it's pretty fast esp with caching enabled.

However ATUM multi-inventory is just way too cumbersome on speed. It is nearly a deal breaker. Is there any way that you guys could optimize atum multi-inventory loading on the products page in the admin?

Salva

Hi Atrix

How many products are you showing per page?
I've just tested it myself with 25 products per page and with MI disabled, the page loaded in 3.6 seconds and with MI enabled it loaded in 4.37 seconds. So the increase in loading time is minimal for me.

FYI, we are already using object caching everywhere (in ATUM and all the add-ons) to improve performance and to avoid duplicated queries too.
Did you check if there is another 3rd party plugin that could be causing some kind of extra delay when MI is enabled?

Best Regards,
Salva.

Atrix

Salva
I was doing 25 products per page, with 500 it took like 70 seconds.

I don't know what plugin would add that much time with atum multi inventory enabled but not cause it while it wasn't. But I did try disabling quite a few and the problem persisted. Can I ask how many TOTAL products your test had?

Atrix

I have two complete xdebug profiler dumps, one with limited plugins and multi inventory enabled and one with limited plugins and multi inventory disabled. The file size of the one with atum enabled is 435MB and the one without atum enabled is 151MB so it's def adding a lot of processing based on that alone.

I'd like to send you both profile dumps is there a way I can do that? it'd allow you to figure out what is taking so much time.

As a last ditch effort i disabled everything but these plugins and still experienced the issue, though the dumps have more enabled:

Admin Menu Editor Version 1.9.7 by Janis Elsts | Auto-updates disabled
Admin Menu Editor Version 1.9.7 by Janis Elsts | Auto-updates disabled
ATUM Inventory Management for WooCommerce Version 1.7.8 by Stock Management Labs™ | Auto-updates disabled
ATUM Multi-Inventory Version 1.4.1 by Stock Management Labs™ | Auto-updates disabled
Disable XML-RPC Version 1.0.1 by Philip Erb | Auto-updates disabled
Query Monitor Version 3.6.4 by John Blackbourn | Auto-updates disabled
Scalability Pro Version 4.62 by Dave Hilditch | Auto-updates disabled
Super Speedy Search Version 2.04 by Dave Hilditch (WP Intense) | Auto-updates disabled
Varnish Caching Version 1.8.3 by Razvan Stanga | Auto-updates disabled
WooCommerce Version 4.6.0 by Automattic | Auto-updates disabled
WooCommerce PayPal Checkout Gateway Version 2.1.0 by WooCommerce | Auto-updates disabled

Simply deactivating atum multi-inventory fixes the time from going from 9.20 seconds to 3 something.

The queries don't seem to be an issue it's definitely something in the php with so many products. Please advise on how to send the profile dumps, thank you.

Atrix

I've delved into the profilers with the min plugins listed above and I tracked it to 100% being ATUM.

Here is two screenshots of the profiler.

https://pasteboard.co/JvRTADZ.png

https://pasteboard.co/JvRTJ3I.png

As you can see, it's adding 29 times more execution time for the part of the loading which renders rows when it's enabled. Note that with profiler enabled the entire execution time was 15 secs without multi-inventory, and 47.85 secs with it enabled, this is normal as profilers add a lot of time to execution. This added time however is still going to be faithful to finding the problem. This all tracks well to everything I have experienced. Each row is adding time to a significant degree and it adds up quickly. Please advise on if you will fix this or not as it is a dealbreaker for us, we'll have 270,000 products and I'm sure the scaling will get worse with not only that but when we add more than a few inventories as well.

Salva

Hi Atrix

Of course that Multi-Inventory can add a little extra loading time to the products list because it must do its own calculations for each product. But it doesn't matter whether you have just 100 products or 1 million as we only process the products that are shown in that load (so if you have 25 products per page, we only process those 25 and nothing more).
So, it's very weird that is delaying so much for you with only 25 products per page and I'm not having such issue with the same number of products. That's why I was thinking that there is something not working as expected on your specific configuration.

Anyway, if you want us to debug this for you, please do open a private ticket and give us access.

Best Regards,
Salva.

Atrix

29x more time per item is a small amount of time? What about 6 seconds to a page load? Also it's wrong to say that only the products listed are affected, doing the same query on one million rows doesn't give the same result time wise as the same query on 10 rows. Your php processing could do additional queries which cause additional time tho it appears to be mostly done with php that is slowing it down so much. I'll open a private ticket but I hope this matter isn't tried to be explained away with inaccurate information and actually fixed. My job shouldn't be to convince you that there's a problem. That it has the problem with it enabled and doesn't with it disabled should be enough evidence and I gave you far more than that.

Salva

Hi Atrix

I was talking about the usual increase in load time not about your specific case.
It's clear that you have an issue there that should be debugged. That's why I asked you to open a private ticket, so we can understand where the problem is and try to fix it out if it's related to us.

So, let's continue with this discussion there, please.

Best Regards,
Salva.

Atrix

Private ticket complete it was multi-inventory, along with the large postmeta table (number of items plays a large part in this). We were given a patch by support. You can close this now thank you to support.

Tommy83

Atrix Can you share this fix with us please?
How it was solved?

BR
Tommy

AndreaRebel

You're welcome @Atrix 🙂

evalast

AndreaRebel - so the problem is gone? thx

AndreaRebel

Hi evalast

Are you experimenting an unusual increase in load time with Multi-Inventory enabled?

Best Regards,

Andrea.

evalast

Hi - no i just came up with this thread i was not sure if it was resolved... thx

AndreaRebel

Hi evalast

Okay 🙂

Best Regards,

Andrea.

Tommy83

Hello,
we running our project on litespeed enterprise server cache with 5 worker!
32 cores with 4,2ghz and 256G memory.
Memory limit we defined 8G.
Redis is enabled.

But our devs and hoster find that issue:
If we enable the ATUM plugins the db and code profiler have a lot of peaks in most of all backend areas caused by ATUM plugins.

+10.000 products.

Any update is planed to fix that issue?

BR
Tommy

japiera

Hi Tommy83,

The issue you are requesting is from four years ago.

I was fixed at that time.

If you are having problems with ATUM Multi Inventory now, please open a private ticket here. We'll be pleased to help you.

But please note that working with multiple inventories for +10.000 products requires a lot of processing time.

Best Regards,
José Andrés