Scale your infrastructure
Warm up your gears: Whether you are running on AWS or Google Cloud, you should start talking to your account manager to warm up 3-4x your current running instances so as to be able to scale with ease, instead of being desperate and out of capacity in the middle of the top sale because you couldn’t anticipate your server’s load.
Make sure you are taking full advantage of the multiple availability zone feature in your cloud hosting as very often there are migrations happening in both Amazon and Google cloud that can affect your platform stability; hence, if one zone is down or having some problems you can still serve your users without any downtime.
Stress test your platform
First of all, prepare for your stress test strategy plan. This is very important before jumping into testing different tools. Start by opening your analytics tool. Most of the common tools offer a User Flow in a stacked column flow or funnels. Create the user steps based on every entry point you have in your platform and create your chart as you can see below:
Or, you can use a different funnel charts for your starting points
(Home, Product, Category and Campaign Pages)
Now that you know where you will start from, here comes the easy part. There are a lot of free tools to perform stress tests on your platform like Apache JMeter, Apache Bench (ab), Siege, and I will be focusing on open source and free tools. The one I will use for our example is called Vegeta, which is very easy to use from your Linux terminal.
Example of Vegeta usage:
1 | $ echo "GET https://www.your-ecommerce.com" | vegeta attack -rate=10 -duration=30s -http2 | vegeta report |
Vegeta is very commonly used in Google to run performance and scalability tests on different parts of their technologies including Kubernetes. (Kubernetes team uses Vegeta in their 10,000,000 QPS load test.)
Website Speed Test
Example of segundamano.mx performance results
Personally, my favorite tool for measuring and improving frontend performance is webpagetest.org as it gives you this beautiful waterfall including what your assets are, what is taking long time and what is impacting your page load time. You can see an example of our page load time here: Segundamano.mx web page test.
Looking at the top right of our results page, you will see the following ranking:
First Byte Time (A): It should always be below 500ms. You should always push for 200 to 300ms.
Apache gzip configurations: (Add the following to your .htaccess file)
1 2 3 4 5 6 7 8 9 | AddOutputFilterByType DEFLATE text/plain AddOutputFilterByType DEFLATE text/html AddOutputFilterByType DEFLATE text/xml AddOutputFilterByType DEFLATE text/css AddOutputFilterByType DEFLATE application/xml AddOutputFilterByType DEFLATE application/xhtml+xml AddOutputFilterByType DEFLATE application/rss+xml AddOutputFilterByType DEFLATE application/javascript AddOutputFilterByType DEFLATE application/x-javascript |
Nginx gzip configurations:
1 2 3 4 5 6 | gzip on; gzip_vary on; gzip_comp_level 6; gzip_proxied any; gzip_types text/plain text/css text/javascript application/javascript application/json application/x-javascript text/xml application/xml application/xml+rss; gzip_disable "MSIE [1-6]\."; # Who still care about IE6 |
Compress images (A): Ensure all the images served are compressed. This is normally a result of configuring your assets bundler. Whether you are using Webpack, Gulp or Rollup, you can easily Google the image compression configuration.
Cache static content (F): Make sure you have a good caching strategy, so that you can cache the most essential assets in your website to make the user experience fast when they are navigating from one page to another. Normally, you will not be able to control caching external of resources, especially if you are adding marketing pixels or tracking pixels since they are handled by the ad server’s provider.
Prepare for Failure
“Anything that can go wrong will go wrong.” Murphy’s law
It doesn’t mean you should accept this law and not prepare yourself for platform failure. There is a way to hack this failure and minimize the risk by being in a mode of “Productive Paranoia” (from the book Great by choice for Collins and Morten Hansen).
Start by writing on your whiteboard the critical and essential parts of your platform which, in case of failing, may take your platform down. Start with your database and then your APIs once you get to the frontend servers. Make an action plan of what you should do if any of these components or microservices fail and how you can recover within the shortest time period.
Security Penetration Test
This year has been a crazy year for security experts and big companies, with lots of ransomwares and data breaches. You’d better be testing every part of your platform and business from cloud infrastructure, apps and even internal infrastructure and performing constant social engineering attempts against your own business to discover early your security vulnerabilities and fix them.
Pray to the server’s gods.
