Enterprise Solutions for Magento
What do you do when you need to modernize Magento 1.9 to Magento 2.2 and at the same time improve speed, reliability, security, and manageability? Who do you turn to that has the expertise, and the tools to get the job done? And deliver it all like yesterday, and before the seasonal holiday rush?
These were the very same questions sketchbubble.com had before approaching aMiSTACX’s consulting arm.
A little about sketchbubble. They just happen to be India’s largest, and one of the world’s largest providers of PowerPoint Templates. Everything you need to save you time when putting together a powerful presentation.
When Pankaj Narang, co-founder of sketchbubble.com, first approached us, even though he had his own development team, he was not interested in our do-it-yourself model. In fact, he basically said, “I need an expert!”. Meaning he wanted aMiSTACX to suggest and deploy the proper AWS infrastructure in order to same his team time.
Magento Migration to aMiSTACX
A few facts about their old hosting provider Codero. They were using a dedicated server, running Magento 1.9, and had very disappointing load times of about 7/8 seconds, no high availability or scalability, and no development environment. They also made use of Amazon CloudFront to handle about 500K images.
Well, first course of action was to outline the game plan. My suggestion was to make use of the aMiSTACX S3 Titanium HA stack for Magento 2.2.x, and at the same time set up a proper development environment.
Migration to AWS
Typically the hardest part of getting started on aMiSTACX on AWS is migration of all of the data. This usually consumes the most bulk time with the only true reward of finally breaking free from your old hosting provider. Sketchbubble was no different. Several tens of GBs of data and images had to be moved to the new development home on AWS.
To make everything easier, we followed our standard routine of mounting our aMiSTACX Windows Utility Server. This helps in many ways. 1. phpMyAdmin access to RDS, 2. An RDP secure desktop interface for developers and admins, 3. Access tools such as Putty and WinSCP.
Our plan was to set up a new production environment, and a new development environment that mirrored the new AWS production environment. All in all three servers. Two Magento stacks and one Windows Utility stack.
While Codero continued to host their Live production site, we would build and test the new, and when all data was in-sync we would just cut the DNS over.
Cloudflare vs. AWS CloudFront
Right away, I recommended using Cloudflare to handle the DNS and CDN; however, their team was skeptical about interfering with their own implementation of AWS CloudFront that was already hosting their Magento media files.
In the beginning, I suggested a compromise until we were later on in the project. We would let Cloudflare handle the DNS and CDN for the Magento Frontend, and let AWS CloudFront handle the backend media files. [More on this later.]
Upgrades Magento 1.9 to 2.2.5 to 2.2.6
Their team handled the upgrade from 1.9 to 2.2.5 [thankfully], and our team handled all of the infrastructure and aMiSTACX S3 Titanium configurations. As Magento 2.2.6 was just released at the time, I suggested we go up to the next version 2.2.6 as 2.3.0 was on the horizon, and it would be much easier to upgrade when the time came. We agreed, and aMiSTACX did a composer upgrade from 2.2.5 to 2.2.6 that was flawless.
The new sketchbubble.com was now running Magento 2.2.6 on our S3 Titanium stack. We explained how the use of S3Sonic and S3R-Alpha can further enhance performance, and we agreed for plans to test both.
Improve Performance
First Round of Load Testing
aMiSTACX has been recommending, and using a online load testing tool called LoadImpact.com [Great tool!].
Our first rounds of tests that ran over several days consisted of running 100 visitors in 15 minutes; to best simulate sketchbubble’s monthly unique visitor numbers. At the time, the AWS infrastructure was Magento 2.2.6 running on a t2-xlarge and a MySQL RDS db.t2.medium, and one aMiSTACX S3Sonic spawned RDS read replica.
Results were not very good as we quickly maxed out the CPU, and the backend RDS was having a hard time keeping up. Additionally, the load times were only in the 4/5 second range. An improvement yes, but not worth all the effort so far. There were clearly issues, but they were hiding themselves.
My suggestions from experience was to first test the aMiSTACX S3R-Alpha module in conjunction with CDN Cloudflare.
As I had discovered during a testing cycle, that sketchbubble was using AWS CloudFront as origin. This means instead of mounting the images on AWS S3, they were still initially served from the EC2 server. This was a potential bottleneck, and the whole reason behind the design of cloud orientated S3R-Alpha module.
S3R-Alpha will offload ALL of the Magento media images, and mount them on S3. At the same time re-write the URLs so Magento can function properly with uploads and ongoing image maintenance. Used in conjunction with Cloudflare CDN they pack a powerful arsenal to increase performance as we were now leveraging a distributed cloud model at the edge.
Second Round of Load Testing
After syncing about 500K image objects to S3, we started our next round of testing. As results clearly improved in stability and slight performance, we were still facing unknown bottlenecks. From experience and customer usage we knew the core issue wasn’t with our stacks, so I turned to other 3rd party modules and the theme as possible culprits.
Most serious performance issues with Magento stem from poorly written modules and themes, and to convince the customer I pointed to the fact that we had a fashion site running on a custom LUMA theme, and an adult site that both loaded in about 1.4 seconds on a t2-micro using the same S3R-Alpha – S3 Titanium configuration.
To further convince the customer, I said, “Let’s run the same 100 in 15 on the aMiSTACX Luma demo site.” When we ran the test, I actually had to ask if the test had even started – lol. As I had been monitoring top from CLI and RDS from AWS, the needle barely moved. Utilization looked almost nil with an occasional few spikes to about 20% CPU usage.
This gave Pankaj an immediate air of confidence that sketchbubble was indeed heading in the right direction as they were running almost the same exact configuration, but their bottlenecks were yet to be discovered.
Waterfalls
Stick to a few testing tools for speed such as GTMetrix, Pingdom, and WebPageTest to set your benchmarks, and then test in rounds of three. Taking the average to set your benchmark. Be realistic and test as close to origin as possible. In our case, we used GTMetrix as the primary tool and WebPageTest.org as secondary.
Quickly we were able to point to some 3rd party APIs that were causing bottlenecks, an obsolete 3rd party warming cache module*, and then we also configured the Magento backend not to bundle JS. As load to the database had been exceptionally high too, their developer also focused on improvement of the database queries from the theme.
Additionally, I suggested offloading certain 3rd party APIs to Cloudflare apps. This way the integration is in the cloud, and not an API embedded in the Magento code on the server.
Customization and Issues
As the customer wanted to use S3R-Alpha with Cloudflare, and put AWS CloudFront out to pasture, we [aMiSTACX] discovered an issue with S3R-Alpha. There was no way to set a custom image path, and our default differed from Magento’s default. This introduced a problem for sketchbubble as this meant potentially all of their image URLs would need to be re-written, and that would potentially impact their SEO.
It’s great to be a Senior Engineer at aMiSTACX, so all it took was a conference with my development team, and we had an aMiSTACX S3R-Alpha upgrade delivered within 48hrs! Now the customer could use a custom or the Magento default image path. Problem solved :))
Dialing-In
Performance Tuning
Like in NASCAR, we did a few tune-up laps before going for our best times.
With theme, module, and 3rd party pain-points identified, it was now time for performance tuning. aMiSTACX reviewed Magento memory and php.ini files and matched them for the larger EC2 t2-xlarge.
Now running the 100 in 15 was reasonable. CPU average dropped to around 20% utilization, and load times dropped into the 3’s. Sketchbubble’s management was pleased with the results as they now had considerable room for growth, truly scalable horizontal and vertical infrastructure, and load times that were very functional,and all without having to re-write their entire Magento marketplace theme from scratch.
New Features – Magento S3 Titanium
While the customer continued to work with their own in-house developer to further enhance the performance with their theme, aMiSTACX was ready to launch a new feature that had been in development for some time, but was not publicly released; Magento Static content deployment to AWS S3.
With Magento Media and Static content [CSS/JS] deployed to AWS S3 and on the Cloudflare CDN [Redis was no longer required] load times dropped into the high 2s with averages in the low 3s! This was the type of enterprise performance the customer was hoping for, paying for, and that aMiSTACX helped deliver.
Note: At the time of this writing, aMiSTACX has released S3R-Alpha 1.0.6 that now includes image compression.
Getting back into the Race
As the customer couldn’t delay going live any longer, it was time to get back into the race. All it took was a simple flip of the DNS switch over at Cloudflare and the new sketchbubble site was live.
Overall the project was a great success, and we [aMiSTACX] even learned a few new things to help increase performance and make the transition to aMiSTACX even easier.
And when you need a kick-ass template for your PowerPoint presentation – be sure to visit sketchbubble.com, at least you know it’s supported by World Class infrastructure and aMiSTACX – an experience that builds trust and confidence. 😉
Need 5-Star Contracting and Development Services?
~ Lead Robot
* Please check out Ramjet Cache Booster to replace your obsolete cache warmers.