At the Magento Imagine Conference today, Tuesday, April 9, 2013, Roy Rubin announced the release of Magento Enterprise Edition version 1.13
Magento Enterprise 1.13 Announced by Roy Rubin, founder of Magento
The biggest benefits to Magento Enterprise Edition (EE) 1.13 are all performance related. These improvements are the hardest to describe to a customer, but for large accounts, are the area that Magento has been most lacking in.
We have received a lot of inquiries over the past 2 years of customers trying to squeeze the most out of Magento We always have some way or another to help them, but the truth is just that Magento is somewhat clunky. The improvements I’ve seen in 1.13 indicate that Magento feels the same way, and the core team is making every effort to remedy that issue (an effort that I hope will come to full fruition in 2.0)
==================================================================
Redis Support
Magento EE 1.13 now support Redis NoSQL as a cacheing session storage solution. I’m not yet sure of the specifics, but this could provide an advantage over memcached — and Magento now recommends using redis on new deployments. It’s not that redis is “faster” in terms of storing cached values, but it has more support for storing objects (I’m getting into some pretty technical stuff here, but the point is, this could be a better cacheing solution assuming the Magento core team implements it correctly). However, I’m not sure how long it will take for hosting solutions like pier1/nexcess to support Redis.
Reindexing
As many of you may have encountered, re-indexing is a pain in the @$$. Especially on sites with large (10,000+ SKUs) catalogs. EE 1.13 supports mysql database triggers as a means of keeping the indexes up to date, and it makes re-indexing an incremental process rather than an en masse process. The Magento core team has also limited the number of instances where a full re-index is required (hopefully never once the store is setup)
From the Magento article:
In Magento Enterprise Edition 1.12, any change to a product would result in a full re-index. Magento Enterprise Edition 1.13 introduces a new feature–incremental re-indexing. With incremental re-indexing, only those items that were changed or added will be re-indexed, reducing the processing time to a fraction of what was required before.
This is huge—I’ve seen stores where store owners are crippled if they update their product data, as reindexing 10,000+ products can take hours. So, this is a big plus. No longer will a store owner need to have a once-a-day product update regiment.
Also, if you look on the bench marking page: http://www.magentocommerce.com/knowledge-base/entry/ee113-performance-and-scalability-white-paper you will see significant improvement in the time required to make a full re-index (53% improvement on 500,000 SKUs!)
Onepage Checkout Speeds
So, whenever a user enters the checkout, Magento can’t rely on all the fancy cacheing layers. And, it’s a known problem that onepage checkout is slow; this is the whole reason onestepcheckout exists. But, even that (I’ve noticed) has problems related to the amount of time it takes to return shipping rates, payment methods, and order review steps.
See this link: http://www.magentocommerce.com/images/uploads/2184-1.13_Benchmark_Report_Checkout_Flow_r1v1.png
You will notice the checkout has been extremely optimized in terms of the amount of time it takes to perform one of these operations. As to the effect that has on the core code, I’m not yet sure. I’m really hopeful this feature will be in CE 1.8 as well.
From the benchmark page:
During our testing, which simulated a storefront running at peak hours, EE 1.13 executed 33% more orders and 31% more page views than Magento Enterprise Edition 1.12 on the multi-node benchmarking configuration. Notably, Magento Enterprise Edition 1.13 served 47K pages during the test run (10 minutes).
This is also a big improvement…once again, it’s only targeted at high volume sites, but I can think of several customers that would benefit from this.
MySQL Performance
I’d like to highlight one of the observations made in the bench marking article:
- The MySQL instance did not show any significant signs of CPU or I/O load during the tests.
- The CPU was under 10% and no queries exceeded a 2-second threshold.
I’ve noticed that MySQL seems to be a memory and CPU hog on some instances of Magento This observation (specifically the no queries beyond 2-second threshold) shows an improvement in the scalability of Magento from a database perspective. Now, I don’t know what Magento’s benchmark for 1.12 was, but I’ve definitely seen stores not getting near the volume that the benchmark took place with, having MySQL performance issues.
Improved Tax Calculations:
There had been problems with tax calculations, especially with rounding up to the one-cent and when using multiple types of currency. The tax calculation algorithm was updated to get rid of errors with rounding offsets when displayed on purchasing screens. Additional support has also been given for various nationalities, primarily Canadian.
Increased Overall Functionality:
A whole slew of over 350 functional improvements for the web store, shopping cart, web API, payment options, import and export functionality, and admin order creation. All of these minor improvements add up to a big difference in the end, which will drastically increase user experience, and make it easier for admins to make changes without worrying over slowing down the whole site.
Why Customer Paradigm?
What`s going on: FedEx is switching over to a newer Web Service API, and is discontinuing their older system at the end of May, 2012
I’m not talking about any sales, I’m talking about holiday sales. Shoppers that are price-sensitive, impatient and quick to click to your nearest competition to get their holiday shopping done.
According to Invesp.com:
Attributes of Online Shoppers:
