Welcome to WebmasterWorld Guest from 18.104.22.168
Forum Moderators: buckworks
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.
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!
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.
ask yourself - you got a big site, but do you really need ALL of it generated in real time by PHP/mysql?
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?