I enjoy building and deploying stuff to the web and this week I decided to put my understanding of how ShopBack does it into words. In this post, I will talk about the consumer facing site of our infrastructure
Amazon AWS
Much of our deployment greatly depended on services provided by amazon
In ShopBack, we follow this reference architecture closely (except for a few tweak of our own)
For one, our DNS service is provided by Cloudflare instead of AWS Route 53. One of the greatest pull factor to use Cloudflare was the ability to provide a security scan layer. As our user base and traffic grew, it became impossible to determine if we are experiencing a DDoS attack or a regular spike in traffic due to marketing pushes. Cloudflare’s frontline server automatically helped us to perform analysis on our incoming traffic.(based on a number of characteristic such as the visitor’s IP address, what resource they are requesting and how frequently they are making a request)
I have to admit Cloudflare’s advanced DDoS protection has saved our asses more than once. https://www.cloudflare.com/ddos/
Serving static files
Recently, we hit a problem with pagespeed. Our score was at a low 60 range. This was because of our recent addition of a feature we called, product listing.
If you have been an avid fan, you would notice the extra 4 sections below our homepage. Initially, this 4 sections have a maximum of 32 images. However, the latest design change increase the number to 48 images and our performance has gotten a big hit. SEO has a serious concern when our page speed decreases drastically, citing concern with page ranking.
Solutions? As all good developers, we started looking towards compression. Serving a 1 mb image to our user is definitely not the way to go. Sadly, S3 does not compress our image automatically. So we wrote a little script to compress our images before uploading to S3 and Cloudfront took care of the rest.
However, this only solve part of the problem in our pagespeed issue. We all agree that loading time of our website could be further improve. So we sat down and started looking at our debugger console in chrome.
160 requests? You got to be kidding! Turns out, there were simply too many resources needed to be downloaded for our users in a single page load. Easy, the solution would be to decrease the number of images to be loaded right? That was exactly my thought as well. As I soon found out, all images and resources were necessary. Operating an eCommerce loyalty website means that our consumer are more attracted to visual elements and removing any of those images would directly affect our business value.
And here we are, back to more googling. A second part of the solution is called Domain Sharding.
Domain sharding is a technique for splitting resources across multiple domains, improving page load time and search engine visibility. When multiple domains are used, browsers are able to download more resources simultaneously, resulting in a faster user experience.
From: https://www.maxcdn.com/one/visual-glossary/domain-sharding-2/?utm_source=text
From the above definition, one would have easily guess that there is a maximum concurrent connections that a browser could make to the same domain. What this means is that all resources would have to queue and compete for the limited number of concurrent connections available. So a simple math calculation of 160/6 would mean 10 sequential requests for a single user.
http://sgdev-blog.blogspot.sg/2014/01/maximum-concurrent-connection-to-same.html
You must be wondering, why would a browser have these limitations? In the beginning of days, web pages are delivered on a single page and a browser would set the maximum concurrent connections to 2 to prevent the server from being overloaded by requests and end up being classify as a DDoS attacker. As we soon found out, this limitation became our very bottleneck. Although, most advance browser has increased this limit, it was not enough for us.
One way to overcome this issue was to split page content across multiple subdomains. Browsers reset the connection limit for each domain and thus allow an additional number of active connection to the same server. Voila! we would just need to introduce more CNAME and point it to the same server.
Because browsers distinguish domains by name rather than by IP address, domain sharding can be performed by a single web server. As long as the server has the bandwidth to support multiple concurrent connections, it can take advantage of domain sharding to quickly distribute content to visitors.
From: https://www.maxcdn.com/one/visual-glossary/domain-sharding-2/?utm_source=text
Not so quick, there is a catch! Adding multiple domain would introduce performance losses as web browsers have to perform additional domain lookup and maintain connection to each domain which results in slower initial load times. Luckily for us, Yahoo has already made a study and found that optimal ratio is 2 to 4 domains.
Domain sharding is a proven tool for increasing web performance and throughput.
Benefits
1. Users see increased performance since webpages can download resources concurrently rather than sequentially.
2. Enterprises see increased user satisfaction since users are able to view and interact with web pages more quickly.
3. Enterprises and users see improved bandwidth usage, allowing more content to be delivered to more users faster.From: https://www.maxcdn.com/one/visual-glossary/domain-sharding-2/?utm_source=text
