How Many Line Items Can Your Adobe Commerce Cart Handle? (Part 1)

How Many Line Items Can Your Adobe Commerce Cart Handle? (Part 1)

Have you ever wondered about how many line items your Adobe Commerce can handle?

The question of how many line items a cart can realistically handle is a critical, yet often unanswered, concern for B2B e-commerce owners. While the technical limits might seem boundless to developers aware of the platform's flexibility, the absence of official guidance leaves customers wishing for at least a ballpark figure from the platform itself.

This question has been on my mind since I was recently involved in a potential B2B Adobe Commerce project. After searching within my LinkedIn network, it was surprising to find a lack of official documentation from Adobe Commerce regarding cart line item limits.

While some platforms explicitly state a limit, such as 500 items (or restrcited to 500), Adobe Commerce appears to have no such defined restriction. Therefore, while theoretically the number might be unlimited, this doesn't provide a practical answer. As a long-time Magento developer, I've decided to conduct some testing in my own time to determine an approximate realistic number.

The TEST

For this test, I utilized a clean installation of Adobe Commerce 2.4.8 with sample data and the default Luma storefront. My local Ubuntu environment consisted of Apache 2.4, PHP 8.3, MySQL 8.0, OpenSearch 2.19, and RabbitMQ 4.1.

Notably, the default ".user.ini" and store configurations were maintained, with "Enable Clear Shopping Cart" set to "Yes," and all "Not Visible Individually" simple products had their visibility updated to "Catalog, Search" (It's worth noting that newer versions like PHP 8.4 and MySQL 8.4 might yield slightly improved performance).

.user.ini

The test environment included a total of four cart price rules, three of which were the default sample data rules without coupon codes.

Admin Cart Price Rules Grid

I used the standard "Order by SKU" CSV upload feature in Adobe Commerce to add products to the cart in bulk. Sticking to simple products and a quantity of one for each, I started with 300 items and incrementally increased the number to 1199 through CSV uploads – and it worked flawlessly each time!

Cart Timings

Adding 1199 products to the cart and loading the cart page took approximately 3 minutes and 22 seconds. Subsequently, loading the cart totals required an additional ~1 minute and 21 seconds, resulting in a total loading time of roughly 4 minutes and 43 seconds.

Despite not applying any coupons, the cart automatically factored in a 20% discount from a pre-existing cart price rule. This suggests that disabling such without coupon rules could potentially lead to faster loading times.

Given the cart loading time of approximately 4 minutes with nearly 1200 products, I decided against increasing the product count further. My next step will be to test with a smaller number of line items, aiming for significantly faster loading times that would be more practical for store owners.

Shopping Cart 1
Shopping Cart (with stopwatch)
Shopping Cart with order totals loaded (with stopwatch)

Checkout Timings

Loading the checkout page took approximately 2 minutes and 13 seconds, followed by an additional 1 minute and 14 seconds to complete the order using the default offline shipping and payment methods.

Checkout step 1 (with stopwatch)
Checkout success (with stopwatch)

Account Order Details Page

The order details page within the "My Account" section loads quickly and presents the ordered items well, thanks to the implemented pagination.

However, the invoices and shipments sections lack this pagination for their respective items. Consequently, loading these pages can take longer and involves cumbersome vertical scrolling for users with numerous orders. Implementing pagination in these sections would significantly improve the user experience.

Admin Order Management

The admin order details page loads quickly, but presents all 1199 items on a single page without pagination, resulting in a cumbersome long scroll. Implementing an AJAX-based pagination for the items within this section would significantly improve usability for store owners.

Admin order details (with items count in search bar)

During the process of creating the invoice and shipment for this large order, I encountered an interesting limitation.

While the invoice creation form initially displayed all 1199 items, the system only processed and created an invoice with a maximum of 1000 items upon submission. Consequently, I had to create a separate invoice for the remaining 199 items.

This behavior, without any apparent warning or notification, could potentially be an overlooked bug, as I only realized the discrepancy later upon noticing a remaining due amount on the order details page.

Admin invoice create form 1 (with items count in search bar)
Admin order invoice details (with items count in search bar)
Admin invoice create form 2 (with items count in search bar)

Interestingly, I encountered a similar limitation when creating the shipment, although this time the system capped it at a maximum of 999 items.

This discrepancy from the 1000-item limit for invoices prompted me to re-test by placing the order again. The verification confirmed this: shipments were limited to 999 items, while invoices allowed 1000.

The rationale behind this variation is puzzling.

Admin order shipment details (with items count in search bar)
Admin shipment create form 2 (with items count in search bar)

Conclusion

Ultimately, I was pleased to confirm that Adobe Commerce (Magento), when properly maintained, is indeed capable of efficiently handling large shopping carts – a testament to its inherent capabilities.

Even with the limitations of my local environment (older PHP and MySQL versions, and limited resources), the results were encouraging. I'm confident that with appropriate hosting and, crucially, a responsible and skilled development team, these performance metrics would be even more impressive.

It's a reminder that platform performance is often a reflection of its environment and the expertise behind it, rather than an inherent flaw in Magento itself.

Building on the initial large-cart test, my next phase involves evaluating performance with a reduced number of line items to optimize loading times.

Beyond that, repeating these tests with the Adobe Commerce B2B modules active, and also within an Adobe Commerce Cloud environment (given Fastly's 300-second frontend timeout), should provide valuable comparative data and reveal interesting performance characteristics.

This initial exploration into Adobe Commerce's large-cart capabilities reveals a platform with significant potential, the realization of which is deeply intertwined with the underlying infrastructure and the expertise applied in its configuration and maintenance.

The contrasting performance metrics and the intriguing limitations encountered highlight the dynamic nature of e-commerce platform performance. Future investigations into varied scenarios will further illuminate best practices for B2B merchants seeking to leverage Adobe Commerce for handling substantial transaction volumes efficiently.

Nice test sandipan, I wonder how this would scale in a more b2b environment with potentially 20 + customers having 500+ items each. As sure 1 person maintaining 1000+ products may work fine but is the potentia knock on effect is for the site as a whole.

Constantin Schürer

🚀 Sales Consultant | eBusiness since 2010 | Drives growth, boosts visibility & streamlines complexity

3mo

Your testing approach provides valuable insights into cart scalability, addressing a common concern for B2B e-commerce. Looking forward to seeing the detailed results and practical recommendations.

Pradip Shah

Founder at luroConnect

3mo

Nice test. Some suggestions to make the test better! 1. With php 8.3, you can enable JIT compilation. Can you enable it and set largish limits ensuring the cart code is indeed in JIT. (JIT is machine code). 2.. Would be curious to see if you can set php slow log to 10, 20, 30 seconds and see the stack traces. Do you see any loops? These are time based stack traces and can give you an idea of how your code is executing. 3. php access log writes a CPU % - can you check the value? It says how much time was spent in php code vs db.

To view or add a comment, sign in

Others also viewed

Explore topics