[quote=Jeremy Farrance;262]In an article last Decemeber - [b]Case Study: Improving shopbelieve.com Performance with Hotcake Commerce[/b] ([url=https://mmmcommerce.com/Resources/Blog/PostId/497/Case-Study-Improving-ShopBelieve-Performance-Hotcakes-Commerce]here[/url]) - under the heading of Database Calls, it was pointed out that "the Mini Cart module was making excessive calls to the database" causing significant performance issues on every page the module was added to. We easily confirmed this was affecting 2 of our HCC sites. Neither client was interested in having us create a replacement. And, unrelated, both sites are still running HCC 1.10.x.

Has the Mini Cart module been fixed in HCC 2.x or 3.x?[/quote]

Great question. Thanks for asking it. When the article says "excessive calls to the database" it's not wrong, but it lacks context. The Mini Cart and the Cart modules both do effectively the same thing. They're rarely on the same page on a website, so they each need to make the necessary calls to determine what's in the cart currently and display any other related information (e.g., discounts, etc.). Essentially, the only differences between the two are the intended use case and the front end design.

On any page that has only the Mini Cart module on it, it needs to do all of the calculations necessary to ensure it shows the customer valid details. There is nothing "excessive" about this.

When the Mini Cart is loaded on a page with the Cart on it, they both do the same thing since they're unaware of each other. I don't believe that we found that there were any additional database calls that weren't necessary, aside from the two modules doing the same job for the same page.

[i]It's worth noting that all database calls across the solution were greatly reduced simply by upgrading to Hotcakes 2.xx, since the data access layer was restructured to increase performance (for reasons like this).[/i]

There's still room for improvement here even if you're on the latest version of Hotcakes. The problem in just "fixing" this "issue" is that it's far more complicated than trying to reduce the database calls when you look at the large number of ways Hotcakes is being used.

The best solution I see that can be put into place is for the Mini Cart and Cart modules to be made aware of each other in some way. For example, they each have a flag that they set to be able to check and see if the work they're about to do has already been done or not. If the flag is set, it waits and then loads the cached cart information generated by the other module. I believe that the best way to achieve this is to decouple the Mini Cart from the Cart module and make it a purely client-side module (and finally make it a skin object). This would allow the Mini Cart to delay it's loading of information, preventing these kinds of issues.

In the meantime, a workaround for this use case would be to not put the Mini Cart on pages that have the Cart module on it already. Honestly, this should be the case already, regardless of this topic. It doesn't make sense to have the Mini Cart or anything else on the Cart page. If a customer has arrived at the Cart page, you primary goal and their only call to action should be to proceed to the Checkout.

[quote] It doesn't make sense to have the Mini Cart or anything else on the Cart page[/quote]

I agree with this point too... having anything else on the cart page distracts the user, i'm a fan of limiting menu too once they get to the cart and checkout steps.

Back on the larger topic of the performance load of the mini cart, in some locations we've found that a simple html/xmp module that has a button back to the cart is sufficient for many users who don't really care about seeing the number of items in the cart as much as a quick way back to the cart if it's not prominent and in the main menu/header.

So in some cases, we've done without a minicart and have just done a button/link