Magento 2.3.2 vs Magento 1.9.4 PHP core performance test
Used this article as a source (https://amasty.com/blog/magento-1-vs-magento-2-performance-comparison-speed-test-results/) and utilizing my experience with the latest Magento 2.3.x versions.
Magento 2 base performance is 2 times slower than older Magento 1
For sure Magento 2.3 is faster than 2.0.0 version. If it is faster than Magento 1 we will check it in this post.
I have some knowledge of PHP and Magento. Also, I have experience in AWS cloud solutions with auto-scaling for e-commerce.
The is my infrastructure: https://github.com/Genaker/TerraformMagentoCloud
My Linked-in: https://www.linkedin.com/in/yehor-shytikov-20a24438/
To create a simple environment for this test shouldn’t be a problem.
My passion is sailing performances in San Francisco Bay and software performance optimization. Everything should go fast!
To test I will use the AWS Spot instance. Amazon advertising 70% Spot savings for this instance type:
With Spot instances, you can scale Magento 2 paying $60/month per C5.xlarge instance instead of 130$/month.
Operation system — Ubuntu Server 18.04 LTS (HVM)
I have installed:
- Nginx 1.14
- PHP 7.2.19
- OPcache enabled
- Magento 2.3.2 and Magento 1.9.4.2
- Magento 2 mode production.
AWS infrastructure:
- Separate RDS for Marinad DB 10+
- Separate ElasticCache for Redis 5.0.4+
Almost everything is ready for the cloud. We just need to add Application Load Balancer and tune-up auto-scaling.
I will use Chrome Developer toolbar and AB (Apache Benchmark) for testing.
All previous performance testing metrics of Magento 1 was made with old PHP 5.6.
Support for PHP7 was developed by community: https://github.com/Inchoo/Inchoo_PHP7
After security updates for PHP 5.6 were stopped on December 31st 2018, the Magento team added support for newer versions of PHP7 to keep Magento 1 secured. And now we can check the real performance.
Aim of the test is to measure core PHP Magento 2/1 framework performance without FPC module or Varnish.
Why this metrics matter? Because you never have 100% FPC coverage. Usually, less than 20–50% for catalog pages. Magento is a random mix of cached and not cached pages. FPC doesn’t work for such type of pages: search results, layered navigation, checkout, cart, POST/AJAX requests, API/GraphQL.
FPC works for guest customers but for an existing customers, Magento generates a new cache the same as per customer group, currency, language, B2B catalog. Also, during daily store maintenance routine: mass price and inventory updates, synchronization with ERP, PIM, DROPSHIP, CRM, re-indexing, after each new code deployment, setup:upgrade cache is flushed. In some cases, also good to flush cache after successful order placement if you have any frontend logic based on product QTY or to correctly show out of stock products. After this, you have 0% cache coverage.
(Magento official documentation about this — https://devdocs.magento.com/guides/v2.3/config-guide/varnish/use-varnish-cache.html)
Sometimes people start looking at caching because they realized, “Oh application is slow, so if we have a Varnish cache, it’s going to be fast.” It’s not exactly right. Like the main reason why you want to do Varnish caching is to reduce server load and allow scaling because you will always have cache misses: like moments when the cache doesn’t know the response and you have to hit the application and if the application takes a few seconds to render a page, some of your users will have a shitty experience. Cache can’t fix that problem. It will have… it will lower the number of people that have a bad experience with Magento 2 but it won’t make the bad experience go away. So the actual like the good motivation for caching is to say we: we want to be able to scale. We want to scale with less servers because if there is many people asking for the same home page, it doesn’t take us a lot of resources. But the application behind should still be in a reasonable shape to deliver pages fast without FPC. That’s why Magento 2 Page Speed without FPC matter.
GitHub issues about FPC :
https://github.com/magento/magento2/issues/21385
https://github.com/magento/magento2/issues/13996
https://github.com/magento/magento2/issues/4422
The cache is also completely flushed after a customer places an order. And sometimes that is every few minutes. So our shop is uncached most of the time.
GuiltyNL
Why not only recreate cache for product that has been edited, and why flush all the cache? If I edit a product my cms pages also get flushed. Really strange behavior that makes Magento almost unusable. I didn’t have this with Magento 1.
KooTjooc
Oleksii Prozhoha CTO at Skynix( https://skynix.co/resources/magento-2-theme-with-react) Magento agency described Magento FPC issue in this way:
Magento 2 e-commerce shop with FPC (PHP or Varnish), will work for the following cases only:
Case 1 — Small shops with less than 1000 visitors per day
In this case, ecommerce team can work during the day, add/edit products, inventory, marketing pages etc.
Magento will flush cache for each action, and during working day with new visits cache will be restored.
Restored and flushed again and again.
It is not good for SEO and Conversion rates, but when there is not a lot of visitors it is acceptable.
Case 2 — Mid size shops with 1000~10,000 visitors per day
In this case, ecommerce shop is limited. Because if their team works with Magento that loses cache during working day, a huge number of visitors will overload even the most powerful server architectures. This will significantly damage their SEO efforts and conversion rates, because the first visit of any page will be very slow, let alone checkout process.
To resolve this, e-commerce shop can instruct their team to work at nights only (not an ideal situation to be in, but it works for some businesses) or set up very expensive architectures with many expensive servers and pay tens of thousands of dollars a month for it.
I will not check page rendering performance which depends on many front-end factors. I will check Magento back-end server response time only.
Response time is, quite simply, critical for web applications. A faster web app — which also uses less memory, reducing the likelihood of page swapping and resulting performance problems — accomplishes three things:
Makes users happier and more likely to visit and complete tasks on your site, such as reading articles, getting product information, hailing a jitney, renting a spare room, or buying things. That is, the reasons you created the site or app in the first place.
Enables a given server to support more users without running the risk that it slows down or even keels over from additional users. Postponing doom is always a good thing.
Nginx
You should reduce your server response time under 200ms. There are dozens of potential factors which may slow down the response of your server: slow application logic, slow database queries, slow routing, frameworks, libraries, resource CPU starvation, or memory starvation. You need to consider all of these factors to improve your server’s response time.
I will use AB tool Waiting metrics. Waiting is the time between writing the last byte of the request and receiving the first byte of the response.
https://httpd.apache.org/docs/2.4/programs/ab.html
Test Scenarios:
- Main Page
- Category
- Filter Layered Navigation
- Search “Shirt”
- Product Page Simple
- Product Page Configurable
- Cart Page
7.1 Test Empty CMS page
I will test each page 10 times with concurrency 1
First I will do warm-up in browse then I will run “ab” command in terminal.
1 Main page M2
ab -n 10 -c 1 -s 1 http://ec2-54-215-221-187.us-west-1.compute.amazonaws.com/
Connection Times (ms)min mean[+/-sd] median max
Connect: 35 37 3.3 36 45
Processing: 423 490 59.8 518 581
Waiting: 201 263 61.7 274 357
Total: 460 527 59.9 553 619Result: 274ms
1.2 Main Page M1
ab -n 10 -c 1 -s 1 http://54.215.221.187/
Connection Times (ms)min mean[+/-sd] median max
Connect: 35 37 3.1 36 45
Processing: 190 202 18.2 196 248
Waiting: 119 127 14.7 122 166
Total: 225 239 17.8 235 284Result: 122ms
274 vs 122. Magento 1 is 124% faster
2.1 Category page M2
ab -n 10 -c 1 http://ec2-54-215-221-187.us-west-1.compute.amazonaws.com/women/bottoms-women/pants-women.html
Connection Times (ms)min mean[+/-sd] median max
Connect: 34 36 0.8 36 37
Processing: 1276 1339 38.0 1348 1410
Waiting: 952 973 13.7 975 995
Total: 1313 1375 37.6 1384 1445Result: 975ms
This Result is a little bit heavy and slow I found another page with less items and without configurable products to test
ab -n 10 -c 1 http://ec2-54-215-221-187.us-west-1.compute.amazonaws.com/gear/bags.html
Connection Times (ms)min mean[+/-sd] median max
Connect: 34 36 1.4 36 39
Processing: 700 863 61.0 875 915
Waiting: 585 606 18.6 607 642
Total: 736 898 61.1 910 950Result: 607ms
2.2 Category M1
ab -n 10 -c 1 http://54.215.221.187/women/tops-blouses.html
Connection Times (ms)min mean[+/-sd] median max
Connect: 35 37 3.2 36 45
Processing: 419 440 9.3 442 454
Waiting: 278 294 8.5 295 311
Total: 459 477 9.6 477 494Result: 295ms
607 vs 295. Magento 1 is 105% faster
3.1 Filter Layered Navigation M2
Connection Times (ms)min mean[+/-sd] median max
Connect: 34 37 4.6 36 50
Processing: 943 970 28.0 959 1018
Waiting: 713 733 20.7 732 777
Total: 978 1008 27.5 994 1054Result: 735ms
3.2 Filter Magento 1
ab -n 10 -c 1 http://54.215.221.187/women/dresses-skirts.html?apparel_type=33
Connection Times (ms)min mean[+/-sd] median max
Connect: 35 36 0.8 36 37
Processing: 382 392 9.0 391 412
Waiting: 265 274 9.3 272 297
Total: 419 428 8.9 427 449Result: 272ms
735 vs 272. Magento 1 is 170% faster
4.1 Search “Shirt”
ab -n 10 -c 1 http://ec2-54-215-221-187.us-west-1.compute.amazonaws.com/catalogsearch/result/?q=shirt
Connection Times (ms)min mean[+/-sd] median max
Connect: 35 35 0.8 35 37
Processing: 797 821 30.4 811 887
Waiting: 574 590 19.0 582 632
Total: 831 856 30.2 847 921Result: 582ms
4.2 Search “Shirt” M1
ab -n 10 -c 1 http://54.215.221.187/catalogsearch/result/?q=shirt
Connection Times (ms)min mean[+/-sd] median max
Connect: 34 36 1.4 36 39
Processing: 359 382 43.3 370 504
Waiting: 246 269 44.8 258 395
Total: 394 417 42.9 404 538Result: 258ms
582 vs 258. Magento 1 is 125% faster
5.1 Simple Product M2
ab -n 10 -c 1 http://ec2-54-215-221-187.us-west-1.compute.amazonaws.com/fusion-backpack.html
Connection Times (ms)min mean[+/-sd] median max
Connect: 34 37 2.8 36 44
Processing: 645 655 11.8 654 680
Waiting: 484 499 12.3 503 524
Total: 681 693 11.2 693 716Result: 503ms
5.2 Simple Product M1
ab -n 10 -c 1 http://54.215.221.187/accessories/bags-luggage/flapover-briefcase.html
Connection Times (ms)min mean[+/-sd] median max
Connect: 34 39 10.0 36 67
Processing: 389 402 13.2 398 432
Waiting: 271 285 14.6 284 321
Total: 424 441 19.0 434 483Result: 284ms
503 vs 284. Magento 1 is 77% faster
6.1 Configurable Product M2
ab -n 10 -c 1 http://ec2-54-215-221-187.us-west-1.compute.amazonaws.com/deirdre-relaxed-fit-capri.htm
Connection Times (ms)min mean[+/-sd] median max
Connect: 35 36 0.9 36 37
Processing: 769 781 11.2 780 800
Waiting: 590 602 10.5 601 620
Total: 805 817 11.0 817 836Result: 601ms
6.2 Configurable Products M1
ab -n 10 -c 1 http://54.215.221.187/women/tops-blouses/nolita-cami-496.html
Connection Times (ms)min mean[+/-sd] median max
Connect: 35 35 0.5 35 36
Processing: 404 429 15.0 429 452
Waiting: 295 315 13.4 311 338
Total: 439 464 15.4 464 487Result: 311ms
601 vs 311. Magento 1 is 93% faster
7. Cart page with configurable product.
I’m testing it in the browser because it needs session.
Magento 2:
Result: 913ms
Magento 1:
Result: 344ms
913 vs 344. Magento 1 is 165% faster
7.1 Empty CMS Page
Why this test? This is lightest possible functionality without content dependencies. Like “Hello, World” program, just framework overhead
Magento 2.3.2:
ab -n 10 -c 1 http://ec2-54-215-221-187.us-west-1.compute.amazonaws.com/test
+--------------------------------------------------+
| Connection Times (ms) |
+-------------+-----+--------------+--------+------+
| | min | mean[+/-sd] | median | max |
+-------------+-----+------+-------+--------+------+
| Connect: | 71 | 198 | 321.9 | 94 | 1111 |
+-------------+-----+------+-------+--------+------+
| Processing: | 211 | 253 | 34.5 | 248 | 311 |
+-------------+-----+------+-------+--------+------+
| Waiting: | 206 | 244 | 37.4 | 231 | 304 |
+-------------+-----+------+-------+--------+------+
| Total: | 282 | 450 | 343.9 | 351 | 1423 |
+-------------+-----+------+-------+--------+------+Magento 1.9.2
ab -n 10 -c 1 http://54.215.221.187/test
147+------------------------------------------------+
| Connection Times (ms) |
+-------------+-----+-------------+--------+-----+
| | min | mean[+/-sd] | median | max |
+-------------+-----+------+------+--------+-----+
| Connect: | 59 | 69 | 7.2 | 69 | 82 |
+-------------+-----+------+------+--------+-----+
| Processing: | 130 | 150 | 20.2 | 147 | 203 |
+-------------+-----+------+------+--------+-----+
| Waiting: | 128 | 149 | 19.6 | 147 | 200 |
+-------------+-----+------+------+--------+-----+
| Total: | 195 | 219 | 22.1 | 222 | 271 |
+-------------+-----+------+------+--------+-----+231 vs 147
Magento 2.3.2 framework adds 57.14% overhead to simplest possible CMS page.
PERFORMANCE TEST RESULTS
+---------------------------------------------------------------+
| Page Response Time (less is better) |
+------------------------------+---------+---------+------------+
| | M 2.3.2 | M 1.9.4 | Difference |
+------------------------------+---------+---------+------------+
| 1. Main Page | 274 | 122 | 124.59% |
+------------------------------+---------+---------+------------+
| 2. Category | 607 | 295 | 105.76% |
+------------------------------+---------+---------+------------+
| 3. Filter Layered Navigation | 735 | 272 | 170.22% |
+------------------------------+---------+---------+------------+
| 4. Search “Shirt” | 582 | 258 | 125.58% |
+------------------------------+---------+---------+------------+
| 5. Product Page Simple | 503 | 284 | 77.11% |
+------------------------------+---------+---------+------------+
| 6. Product Page Configurable | 601 | 311 | 93.25% |
+------------------------------+---------+---------+------------+
| 7. Cart Page | 913 | 344 | 165.41% |
+------------------------------+---------+---------+------------+Conclusion: Magento 1.9 vs 2.3 approximately 2 times faster.
Performance of Magento Framework 2.3.2 is still slower than Magento 1.
We need to optimize our software because slow not optimized apps are more energy consuming and leave bigger carbon footprint behind and are irreversible.
We cannot solve a crisis without treating it as a crisis. And if solutions within the system are so impossible to find, then maybe we should change the system itself.
Greta Thunberg
Magenento with FPC test
Let’s test both Magentos with FPC module performance.
For Magento 1 I will use Amasty FPC extension.
https://amasty.com/magento-full-page-cache.html
Magento 2 Test:
ab -n 10 -c 1 http://ec2-54-215-221-187.us-west-1.compute.amazonaws.com/deirdre-relaxed-fit-capri.html
Connection Times (ms)min mean[+/-sd] median max
Connect: 34 36 1.8 36 40
Processing: 251 260 9.0 259 280
Waiting: 97 108 10.5 106 133
Total: 286 296 8.9 296 315Result: 106ms
Magento 1 Test:
Connection Times (ms)min mean[+/-sd] median max
Connect: 35 37 4.1 36 48
Processing: 212 233 51.4 219 379
Waiting: 135 154 45.3 141 282
Total: 247 270 51.1 255 415Result: 141ms
Magento 2 is 24.82% faster with FPC enabled for single request. But by the nature of the M2 and M1 FPC might have one problem.
Magento 1 uses a hole punching for private content — Private content is already included in the cached page.
Magento 2 generates several AJAX request to receive private content per each page and generates additional loads on PHP server. In case of Varnish Magento also generates this load. For example, Varnish can handle millions request. Magento back-end server handles the same amount of requests for private (cart,compare,wish-list,user data) content data. The other way, one Varnish response produces 1–3 AJAX requests to the back-end.
Magento 2 FPC Varnish scalability issue
When your site gets swamped by a huge amount of visitors, tools like Varnish can improve scalability for static sites, but when user-specific content is needed, a hit to the backend webserver is still needed, causing scalability issues.
Examples of additional user-specific requests in Magento 2:
http://ec2-54-215-221-187.us-west-1.compute.amazonaws.com/customer/section/load/?sections=cart%2Ccustomer%2Ccompare-products%2Clast-ordered-items%2Cdirectory-data%2Cinstant-purchase%2Ccaptcha%2Cpersistent%2Cwishlist%2Crecently_viewed_product%2Crecently_compared_product%2Cproduct_data_storage%2Cpaypal-billing-agreement%2Ccheckout-fields%2Ccollection-point-result%2Cpickup-location-result%2Creview&force_new_section_timestamp=false&_=1568720029639– 176 ms
http://ec2-54-215-221-187.us-west-1.compute.amazonaws.com/customer/section/load/?sections=directory-data&force_new_section_timestamp=false&_=1568720029640–291 ms
http://ec2-54-215-221-187.us-west-1.compute.amazonaws.com/customer/section/load/?sections=cart&force_new_section_timestamp=false&_=1568720029641 — with empty cart 243ms, after adding product to cart response time raised almost twice 450ms
These requests generate significant loads to the back-end server. Good solution to resolve this issue is Magento 2 Node.js serverless microservices for AJAX running on AWS Lambda. Ask me how?
Magento 1 with FPC generates only one page in range 100–250ms without any additional server load by Ajax.
Good article about differences of FPC in M1 and M2 — https://inviqa.com/blog/how-full-page-cache-works-magento-2
Test FPC with load Magento 2 vs Magento 1
Lets test PHP FPC in load fifth AJAX
Magento 2 + AJAX concurrency 45
Concurrency Level: 45Time taken for tests: 17.429 seconds
Complete requests: 500
Failed requests: 0
Total transferred: 39507000 bytes
HTML transferred: 39224500 bytesRequests per second: 28.69 [#/sec] (mean)
Time per request: 1568.596 [ms] (mean)
Time per request: 34.858 [ms] (mean, across all concurrent requests)
Transfer rate: 2213.63 [Kbytes/sec] receivedConnection Times (ms)min mean[+/-sd] median max
Connect: 14 159 359.2 25 2074
Processing: 178 1268 906.6 1106 5091
Waiting: 83 719 440.0 698 3782
Total: 215 1427 962.8 1221 5814Result: 698ms
Magento 1 concurrency 45
Concurrency Level: 45Time taken for tests: 11.668 seconds
Complete requests: 500
Failed requests: 0
Total transferred: 23475500 bytes
HTML transferred: 23261500 bytesRequests per second: 42.85 [#/sec] (mean)
Time per request: 1050.086 [ms] (mean)
Time per request: 23.335 [ms] (mean, across all concurrent requests)
Transfer rate: 1964.86 [Kbytes/sec] receivedConnection Times (ms)min mean[+/-sd] median max
Connect: 14 84 224.1 27 1065
Processing: 179 829 426.0 817 2337
Waiting: 119 508 240.9 498 1939
Total: 194 913 485.9 872 2648Result: 498ms
Magento 2 + AJAX concurrency 20
Document Path: /deirdre-relaxed-fit-capri.html
Document Length: 78449 bytesConcurrency Level: 20Time taken for tests: 13.330 seconds
Complete requests: 500
Failed requests: 0
Total transferred: 39507000 bytes
HTML transferred: 39224500 bytes
Requests per second: 37.51 [#/sec] (mean)
Time per request: 533.190 [ms] (mean)
Time per request: 26.659 [ms] (mean, across all concurrent requests)
Transfer rate: 2894.36 [Kbytes/sec] receivedConnection Times (ms)min mean[+/-sd] median max
Connect: 14 37 100.6 26 1047
Processing: 190 493 462.0 414 4543
Waiting: 83 223 88.0 213 1000
Total: 207 530 468.2 438 4575Result: 312ms
Magento 1 concurrency 20
Magento 1 concurrency 20
Document Path: /chelsea-tee-720.html/
Document Length: 46530 bytesConcurrency Level: 20Time taken for tests: 12.607 seconds
Complete requests: 500
Failed requests: 0
Total transferred: 23479000 bytes
HTML transferred: 23265000 bytesRequests per second: 39.66 [#/sec] (mean)
Time per request: 504.295 [ms] (mean)
Time per request: 25.215 [ms] (mean, across all concurrent requests)
Transfer rate: 1818.67 [Kbytes/sec] receivedConnection Times (ms)min mean[+/-sd] median max
Connect: 14 25 46.3 22 1049
Processing: 175 394 484.0 293 4709
Waiting: 120 232 95.1 214 972
Total: 211 419 485.1 317 4727Result: 214ms
+------------------------+---------+-----------+------------+
| | M 2.3.2 | M 1.9.4.2 | Difference |
+------------------------+---------+-----------+------------+
| 8. FPC single request | 106 | 141 | -24.82% |
+------------------------+---------+-----------+------------+
| 9. FPC/AJAX conc 45 | 698 | 498 | 40.16% |
+------------------------+---------+-----------+------------+
| 10. FPC/AJAX conc 20 | 213 | 214 | -0.47% |
+------------------------+---------+-----------+------------+I will not test Varnish cache performance, it is out of the scope of my Magento core PHP framework speed test. Varnish good and can help resolve slow back-end issue of Magento 2, but core performance will be the same, it doesn’t speedup PHP. Varnish is not necessarily the panacea many think it is. Magento 1 also has community driving Varnish module (https://github.com/nexcess/magento-turpentine).
I have an idea how to deal with stubborn Magento 2 FPC. I have the solution written on C++ and designed specialty for Magento 2 (SaaS) to replace Varnish. Varnish is for CDN not for critical content like catalog pages.
Using this solution web server will deliver old page version very fast while Magento rendering the new page content in the background.
The critical benefit of solution is that all users are always served from cache, including the first user. The first user to attempt access to certain new pieces of content often pays a penalty in terms of page loading speed.
Site performance and FPC cache hit rates can be significantly improved.
According to section.io vision of Varnish proxy caching it is the way to hide poor performance framework from visitors:
Many websites depend on caches. A cache is a system that stores portions of the website in high-performance storage to help avoid reading from systems that have poor performance or to reduce pressure on bottlenecks in the system.
https://www.section.io/blog/advantages-and-disadvantages-of-cache-warming/
In the next test I will show the difference in response time of Magento 2.3.x and Magento 2.0.0.
Pivot table with all results
+---------------------------------------------------------------+
| Page Response Time (less is better) |
+------------------------------+---------+---------+------------+
| | M 2.3.2 | M 1.9.4 | Difference |
+------------------------------+---------+---------+------------+
| 1. Main Page | 274 | 122 | 124.59% |
+------------------------------+---------+---------+------------+
| 2. Category | 607 | 295 | 105.76% |
+------------------------------+---------+---------+------------+
| 3. Filter Layered Navigation | 735 | 272 | 170.22% |
+------------------------------+---------+---------+------------+
| 4. Search “Shirt” | 582 | 258 | 125.58% |
+------------------------------+---------+---------+------------+
| 5. Product Page Simple | 503 | 284 | 77.11% |
+------------------------------+---------+---------+------------+
| 6. Product Page configurable | 601 | 311 | 93.25% |
+------------------------------+---------+---------+------------+
| 7. Cart Page | 913 | 344 | 165.41% |
+------------------------------+---------+---------+------------+
| 8. FPC - single request | 106 | 141 | -24.82% |
+------------------------------+---------+---------+------------+
| 9. FPC/AJAX concurrence 45 | 698 | 498 | 40.16% |
+------------------------------+---------+---------+------------+
| 10. FPC/AJAX concurrence 20 | 213 | 214 | -0.47% |
+------------------------------+---------+---------+------------+This test is my personal vision of web app performance and shouldn’t be treated as an advice and do not guarantee that it’s true or reliable. You can do your own test using different configuration and testing methodology.
Just in case, official Magento 2.0 EE vs Magento 1.14 EE performance result: https://magento.com/sites/default/files8/2018-10/White-Paper-Magento-2_0-Performance-and-Scalability-03_31_16.pdf
Catalog browsing server response times show the Magento Enterprise Edition 2.0 integration with Varnish provides nearly instant responses for cached content. It also generates new pages up to 50% faster than Magento Enterprise Edition 1.14.2 for situation where there is a cache miss or cold cache
Magento 2 has big performance technical debt that must be resolved.
Community Comments:
It’s my experience too! Magento 2.1.x is much slower than Magento 1.9.3.x! — That’s a fact! — I realized that by installing on my root server and checked response time! — At first I thought that the server configuration is not optimal, but everything was perfect. Then I compared 19.9.3.3 and 2.1.7 and it was obvious, that Magento 2.1.7 had overall twice the response time than Magento 1.9.3.3. — My conclusion is, that Magento 2.1.7 is really a cost factor, because you need more server performance to get the same response time!
Gabriel
That’s the worst part of it, out of the box in production mode it’s slower than Magento 1.x I mean yeah Magento 1 had it’s quirks but at least stuff worked.
donkey_is_wonkey
That M2 is slow is no illusion from what I have seen so far. M2 stores with a TTFB < 200ms do not exist in practice, just in tests where people reload and reload to fill the caching layers. Also from the hosting side, M2 resource usage is at least twice as heavy as M1 — without really providing any new benefits.
It was possible to run M1 in realtime without full page caching (just with the block caches etc) with response times between 150ms and 450ms — if there were no blunders in the code. With M2 it seems the dev team has painted itself into the caching corner (using the mindset of “if it does not perform, just cache it”), and that any category page (or any other page displaying a set if products) that is not in the cache will have response times _starting_ at 1s and upwards (often much more, 3–4–5–6–7–8 seconds is very common).
If we read between the lines, don’t expect to improve performance of your magento site if you don’t use Varnish…. compare to 1.9.x versions…
Aurélien
I thought one of the benefits of Magento 2 was speed? how come it is slow! also, I do not like to rely fully on FPC for fast page loads. The application itself should be fast too.
Joshua
Magento 2 can be several times hungrier for your server resources than M1. So a store that used to work on several servers could migrate to a 3-server setup where for Magento 1 you could do just fine with a simpler hardware solution.
No not at all Magento2 is not faster as compared to magento1.9.x , if you are benchmarking both of the platforms with same data set and with same hardware you will realise the same . We are doing such kind of benchmarking everyday at cloudkul, we knew it very well what we are talking about . Magento2 for such includes more tech stacks but that doesnt means that magento2 consumes less time to perform .
Magento2 does require additional CPU usage to perform, For sure magento2 offer FPC in their core which works very fine with Varnish but that can be optimised by using Nginx as a reverse proxy with magento 1.9.x .
We have written extensively here comparing magento 1.9.x and magento2 with varnish and nginx.
Magento2 perform much better with PHP7 as magento2 offers native support for php7 but even using magento2 with php7 is slower to magento1
Vipin Sahu, Co-Founder at Webkul Software Private Limited
That all depends on how you configure your Magento 1 and Magento 2. If we compare default versions than Magento 2 has Full Page Cache (FPC) already built-in which formally makes it faster than Magento 1. But if you install FPC on Magento 1 the answer might not be so trivial.
However, it may be really difficult to estimate the actual performance of Magento 2. While Magento 2 is declared to be a much faster platform in comparison with the first version, different performance tests show less optimistic results. MageCore’s performance benchmark results show that Magento 2 performed slower for the same load test scenario and data sets than the latest Magento 1.x. On the other hand, Performance test of Amasty shows that Magento 2 doesn’t cache search results and Magento 2 production mode is much faster than developer mode. Besides, Magento team has gotten other results proving that Magento 2 really has better performance.
Magento 2.0 + PHP7 + Varnish 4 handles 2.1 M more catalog views and processes up to 135K more orders per hour (36 orders/sec). Magento 2.0 catalog pages are 47–56% faster than Magento 1.9. Magento 2.0 guest checkout is 38% faster. However, the competition between Magento 1.9 vs Magento 2 + Varnish can not be considered fair as it’s not really a test between the “out of the box” Magento 1.9 and Magento 2. Magento 2.0 can empower your web store but it needs additional investing in your hardware and software.Eltrino team
When compared to Magento 1, Magento 2 preformed slower for the same load test scenario and data sets. The results clearly indicates that Magento 2 must run on a more powerful server in order to operate properly or at the same level of Magento 1. Even when a proper server is selected, Magento 2 performance is still lagging behind when compared to Magento 1. The need for additional CPU resources will increase server hosting expenses by 7X (it is for version 2.0.0 version 2.3.2 should have 2–3 resource difference) as Magento 1 performance on C4.XLARGE ($0.239/h) is almost the same as Magento 2 performance on C4.8XLARGE ($1.675/h).
MageCore
Similar test results resources :
https://www.goivvy.com/blog/magento-1924-magento-214-performance-benchmark
https://amasty.com/blog/magento-1-vs-magento-2-performance-comparison-speed-test-results/
Disclaimer:
This material is my personal opinion about web app performance and shouldn’t be treated as advice and don’t guarantee that it’s true or that it’s reliable.
The opinions expressed in this blog are my own views, and I have based my review on my personal experience after purchasing, and using these products. I have no affiliation with the manufacturers, nor is my blog sponsored by any of them. I also cannot vouch for the absoluteness of my suggestions. Use discretion before buying or utilizing any product, and seek professional counsel in case of any issue.
