Quote:
|
Originally Posted by groovico
The problem with that is larger x-cart sites get slower (try comparing the brute speed of an x-cart 3 site with 60,000 customer records/200,000 orders/5000 products to an x-cart 4.X site with the same size of DB).
|
That's not entirely true about the speed groovico our site is a lot larger than that and we have no speed problems (we deal close to 200k unique visitors a month). Then again there are a few things that have to be taken into account:
- I re-optimized and cleaned up a lot of procedural code
- I re-optimized the SQL tables and queries to be ANSI compliant
- Our database software is static custom compiled and aggressively tuned. [Current cart is on MySQL but the new one is flipping over to PostgreSQL for integration reasons]
I've done this both for our current cart (4.1.12) and the new one (4.2.3) making significantly large clean ups. X-Cart can house a large shop it just has to be tuned for it. Now let's take into account how big our database for the cart is (this does not include our internal databases where we process everything for shipments, etc):
141,818 Products
6,424 Categories
1,000+ Special Offers
110,000+ Customers
250,000+ Orders
When it comes down to it, most of X-Cart's bottle necks are actually in it's database design. If a large portion of the SQL database was repaired and the badly written queries were eliminated the software would be fine. I found at least 20+ core critical queries that were badly written that had to be repaired (and 70% of the tables missing required indexes). Granted the code base isn't any cleaner, I had to completely re-write most of the modules due to inefficient coding (X-SpecialOffers is the one that had the most bugs). There's also a lot of what X-Cart can do that should be transferred over to SQL Triggers and Stored Procedures. Using an interpreted language to do SQL maintenance is a DB no-no (for instance the Rebuild Cache for quick_prices, quick_flags, subcounts, etc should be a native SQL function, we're already doing that) simply because SQL can do it a lot faster.