Shopping cart for large inventory

[followgreg]

Hi,

I was wondering if someone knew of a shopping cart solution that can handle over 200,000 products? (php/mysql)

I seem not to be able to find anything decent for some reason :)

[cbarling]

It's quite hard to find a cart that will handle this number because most merchants have a lot less products.

If the ecommerce solution is a desktop application, then it may cache products (mine does) for fast performance, but that can limit the max number.

If it's a 100% online cart, it's hard to create something that can handle that sort of number of products without being very clunky.

Sorry.

Chris

[followgreg]

Actually we already managed to do it with one of our sites (storefront based, bulky and not reliable) but looking for another solution...

I which I could find something else than the current stuff we have in PHP.

[shri]

I've got a modified xcart which runs at about 120,000 products (books and dvds) and while it works .. I know we'll have to migrate to something more stable in a years time when traffic picks up.

[digicam]

Hi Shri how do you physically manage such a large inventory?

[shri]

digicam: we don't keep inventory -- almost real time orders go out to the distributors who ship the product to us. We're not US based, so the customers don't mind a short delay.

[sja65]

What kind of problems do these shopping carts have? I use custom software with over 300,000 products, and I can't imagine writing software that wouldn't scale.

[followgreg]

sja65: I know, it's pretty stupid but most shopping cart softwares did not include scalability in their plans.

Bottom line is that an entry level app. like xcart runs wells under 20,000 but that's it unless you customize it + use a strongly configured dedicated server.

So far I haven't found even one shopping cart close to be able to handle more than 50,000 products out of the box, and that definetely drives me nuts!

[shri]

>> What kind of problems do these shopping carts have?

Most of it is bad SQL queries in the wrong places. For example, some of them dynamically rebuild the whole category tree on every page load (resulting in 8000 cats getting loaded in memory).

Imagine this happening when google, ask, yahoo and msn hit the site at the same time.

Took us a good two weeks to strip down a lot of these excessive SQL calls and we had to split the server into three bits .. one for the frontend (dual xeon shared with other sites), one for the database (P4 on a software raid) and one for the images (P4 on a software raid).

So, problems which were not solved by software, ended beign solved by brute force hardware.

[watercrazed]

Yeh, and they all advertise unlimited products

[followgreg]

Yeah but brut hardware has a cost, damn expensive - Tough for small guys!

[RailMan]

the sheer number of SQL queries in large sites can add a massive hardware load - i reduced that by generating static HTML pages from the database - we do this from a cron job overnight when server load is lower - even generating partly static HTML pages is a big help sometimes

ask yourself - you got a big site, but do you really need ALL of it generated in real time by PHP/mysql?

[sprattoo]

I would LOVE to find a workable cart for dummies like myself.

I am having a hard time getting my 1,000 +/-products online say nothing about 200,000.

I need the simplicity that bcentral cart offers, but is actually usable for non-programmers.
is there such a thing?

[Peter Cornstalk]

You might want to check out SoftSlate Commerce.