If you’re actually measuring scale in eCommerce, the relevant metric is transactions/second. That is how many orders the DB can intake in a fixed period of 1 second. The number of SKUs is pretty irrelevant because DB reads are way faster than DB writes. And you can put a cache like Varnish in front of static pages to skip DB read all together.
This is where “fat” platforms like Magento will blow WordPress out of the water. WP is not engineered for high-scale write operations. It’s impossible for it to compete with a platform designed specifically for performing under this duress.
That may not be your exact concern, but the same principle applies to any discussion between WordPress add-ons for eCommerce and a single-purpose platform like Magento. Shipping, payments, taxes, inventory, wholesale, CRM, rewards, 3rd party integrations, APIs — everything a store needs out-of-box will be more mature on a native eCommerce platform.
If you’re actually measuring scale in eCommerce, the relevant metric is transactions/second. That is how many orders the DB can intake in a fixed period of 1 second. The number of SKUs is pretty irrelevant because DB reads are way faster than DB writes. And you can put a cache like Varnish in front of static pages to skip DB read all together.
This is where “fat” platforms like Magento will blow WordPress out of the water. WP is not engineered for high-scale write operations. It’s impossible for it to compete with a platform designed specifically for performing under this duress.
That may not be your exact concern, but the same principle applies to any discussion between WordPress add-ons for eCommerce and a single-purpose platform like Magento. Shipping, payments, taxes, inventory, wholesale, CRM, rewards, 3rd party integrations, APIs — everything a store needs out-of-box will be more mature on a native eCommerce platform.
I have clients with over 100,000 affiliated products in their WooCommerce stores. It’s definitely possible, just not on a crappy host and you have to be careful about which plugins you use as some of them are written very badly.
e.g. If you install HHVM instead of PHP-FPM then you will get significant speed boosts. I wrote about it here.
If you’re actually measuring scale in eCommerce, the relevant metric is transactions/second. That is how many orders the DB can intake in a fixed period of 1 second. The number of SKUs is pretty irrelevant because DB reads are way faster than DB writes. And you can put a cache like Varnish in front of static pages to skip DB read all together.
This is where “fat” platforms like Magento will blow WordPress out of the water. WP is not engineered for high-scale write operations. It’s impossible for it to compete with a platform designed specifically for performing under this duress.
That may not be your exact concern, but the same principle applies to any discussion between WordPress add-ons for eCommerce and a single-purpose platform like Magento. Shipping, payments, taxes, inventory, wholesale, CRM, rewards, 3rd party integrations, APIs — everything a store needs out-of-box will be more mature on a native eCommerce platform.
Thanks gravitydept, but some well configured WooCommerce stores can handle thousands of transactions/day.
Just wondering, what do you think of Magento vs Demandware, Hybris and other enterprise level ecommerce solutions?
However, Magento is fundamentally using an EAV data structure which by necessity requires a lot of caching and indexing with consequently periodic heavy server loads.
In this respect, Magento was in my opinion doomed to failure right from the beginning (at least as a deployed system) as these problems are not trivial to fix for companies without unlimited budgets and there is no instruction manual that helps.
Here’s some comments from LinkedIn, when people compare Magento to truly enterprise ecommerce solutions. Interestingly, Magento is said to be only for small time retailers
However, Magento is fundamentally using an EAV data structure which by necessity requires a lot of caching and indexing with consequently periodic heavy server loads.
In this respect, Magento was in my opinion doomed to failure right from the beginning (at least as a deployed system) as these problems are not trivial to fix for companies without unlimited budgets and there is no instruction manual that helps.
No. There simply are things that you cannot do without using the EAV model, it’s just impossible. The alternative to the EAV model is to have dozen columns in your tables and be able to add/remove columns depending on your data, which fails big time if you’re modeling your data in a MVC architecture where you need to write queries depending on your columns, and you do need to do that. So no, EAV isn’t bad, it’s just slow by nature and there’s no replacement in rdbms world.
As for using hhvm/hack, this is questionable if all what you are doing is to use the original php files and not writing your code in hack where the compiler can then optimize your code. You could as well use an opcode cache and get same, if not better, performance improvements.
For the OP, wordpress itself isn’t really the fastest cms out there and it will easily cripple small vps’es. But again, if performance is your concern, throw it on powerful machine(s) and be done with it, hardware is cheap nowadays. Anyway, i personally am against using things on top of things that were not designed to do those things in the first place, if you get what i mean. It’s like using PHP for doing networking stuff, surely it’s possible, slow as hell and restrictive, but possible. On the other hand C is a better tool for this.
Somebody recommended setting up varnish, but last time when i checked(this might have been changed from then), varnish over ssl was a nightmare to setup and when you get it going, you get all sort of nasty surprizes.
Using HHVM without changing any PHP code is not questionable - I’ve measured it and with woocommerce I get an 18 fold speed increase on many pages when there are 100,000 products in the store.
Others with more testing resources than me have tested it on more systems and typically see a 6 fold speed increase. (e.g. WPEngine)
I meant measurable against an opcode cache not plain php of course. Don’t jump ship that easy, you’re not facebook to have issues with php itself, but rather with the database usage, and hhvm can’t help you there.
I meant measurable against an opcode cache not plain php of course. Don’t jump ship that easy, you’re not facebook to have issues with php itself, but rather with the database usage, and hhvm can’t help you there.
Except I have to solve performance problems for my clients and the problems with woocommerce performance are NOT in the database when you’re running a large store, they are in PHP. The code in question is some pretty crappy core Wordpress and core WooCommerce code which iterates through every product in your database in order to perform category counts. The mysql code for this with 130,000 products runs on an 8-core VPS in 200ms but then the iteration through all these products in PHP takes 180+ seconds.
When I switched to using HHVM, this same code takes a few seconds to complete because it’s now running compiled code.
You’re going to start seeing a LOT of hosts switching to Nginx + HHVM to solve wordpress performance because it really works, really well.
It would be great if the underlying code were fixed too - this is something I’m also working on to try and figure out how to change the core code without affecting functionality.
Except I have to solve performance problems for my clients and the problems with woocommerce performance are NOT in the database when you’re running a large store, they are in PHP. The code in question is some pretty crappy core Wordpress and core WooCommerce code which iterates through every product in your database in order to perform category counts. The mysql code for this with 130,000 products runs on an 8-core VPS in 200ms but then the iteration through all these products in PHP takes 180+ seconds.
I see... I don't use wp/woo at all for the reasons i listed above, but from what you're saying, it's pretty bad.
Thanks for sharing though, helps others avoid this pitfall
I meant measurable against an opcode cache not plain php of course. Don’t jump ship that easy, you’re not facebook to have issues with php itself, but rather with the database usage, and hhvm can’t help you there.
Except I have to solve performance problems for my clients and the problems with woocommerce performance are NOT in the database when you’re running a large store, they are in PHP. The code in question is some pretty crappy core Wordpress and core WooCommerce code which iterates through every product in your database in order to perform category counts. The mysql code for this with 130,000 products runs on an 8-core VPS in 200ms but then the iteration through all these products in PHP takes 180+ seconds.
When I switched to using HHVM, this same code takes a few seconds to complete because it’s now running compiled code.
You’re going to start seeing a LOT of hosts switching to Nginx + HHVM to solve wordpress performance because it really works, really well.
It would be great if the underlying code were fixed too - this is something I’m also working on to try and figure out how to change the core code without affecting functionality.
Isn’t there anyway for wordpress + woocommerce with 130k of products be faster with some database tuning?
And which portions of the core is causing a performance problem? I’m sure Wordpress contributors like Mark Jaquith and the rest would be keen to fix those
Yes - I mean from my own performance analysis, it boils down to two separate parts of the page - both of which are related to counting products (or posts) per category and displaying category lists. This is something that could be done inside mysql instead of inside the PHP code - as it stands, all product IDs plus a couple of other columns are returned to PHP and the work is done there instead which is really stupid.
Currently - the mysql code runs fast - 0.3 seconds - it’s the fact that ALL rows are returned and then parsed in PHP that causes the problem. I’m sure I’ll figure out a fix for it soon enough but if you want to put me in touch with Mark Jaquith I’d definitely appreciate it - as would a lot of people trying to use Woocommerce for large affiliate stores.
