You are currently browsing the tag archive for the ‘retail’ tag.

As everyone knows, retail is an extremely seasonal industry. Retail E-Commerce is no different so when building an environment to support a retail site, architects and engineers have to plan for the highest demand. Let’s pretend cloud computing doesn’t exist or isn’t feasible in this case.


You’ve got a site that has an average daily peak of 50Mbps but on Black Friday, the peak is 1.2Gbps. Besides Black Friday, no other day of the year exceeds 200Mbps. Naturally ISPs can provide burstable ethernet so you’re only paying for what you use, but switches, load balancers, etc might not provide the same capability. So, you might have to build (and buy) an infrastructure that supports 10 Gbps to provide for your “peak” growth as that 1.2Gbps number might grow at 40% a year or more.


Before building out this environment though, it might be beneficial to learn more about your “peak” demand. For instance, let’s say the peak happens at midnight on Black Friday and that it’s sustained from 12:00 – 12:50 AM. High demand continues the rest of the day, but never exceeds 500Mbps. Why are so many people hitting your site from 12:00 – 12:50 AM? Let’s assume the marketing people tell us that they release some sort of promotion allowing shoppers huge discounts starting at 12:00 AM and going throughout the day. Unfortunately, there’s only enough inventory for 100 of each discounted item, so shoppers hit the site as soon as they’re available.


Before this conversation, we were planning on building an infrastructure to support that 1.2Gbps (and beyond) number that’s only hit once per year, and for only an hour. Now that we know more about why that time period is so popular, it’s time to determine whether it’s “cost-effective.” Let’s say we’re spending $1M extra to support demand that exceeds 1Gbps. If we want to avoid that spend, what options do we have to keep our traffic spikes under 1Gbps? What if the promotions are released the night before Thanksgiving? What if different promotions were released each hour during the day? What if there was enough inventory to assure all customers the items they want? What if promotions were e-mailed to different customers at different times? Obviously a marketing group would be better able to answer these questions than I, but there’s a decent chance that such methods could eliminate the short (duration), large (size) spike. Perhaps rather than a 1.2Gbps spike from 12:00 – 12:50 AM, we see a 500Mbps spike from 11:00 PM – 3:00 AM. Assuming profitability isn’t tied to when folks are buying goods, such a change in traffic spikes would allow us to delay a large expense for at least another year.


Naturally, retail is a great arena for public cloud. What happens, though, when all retailers are on public cloud? Wouldn’t the cloud provider have to have a huge hardware footprint to support Black Friday for all of its retail customers? At any rate, supporting seasonal demand is definitely a challenge, but it poses some interesting opportunities.


One of my great “ah, ha!” moments in Application Delivery came when I was reading a post about compression by F5’s Lori MacVittie. At the time, I was with my previous employer and was considering starting a project to implement compression. When I began discussing it with others, I was told that certain versions of IE had issues with compressed data, even though they sent headers saying they accepted gzip. Since our customers were long term care facilities and could feasibly have older technologies, it wasn’t crazy to think they’d be browsing using pre-IE6 and might have problems. Since our principle rule in IT was to “First Do No Harm,” I didn’t want to cause a negative experience for some users simply to speed things up for others. My mistake at that time was that I made a blanket assumption about all users. I decided that because I shouldn’t compress content for older browsers, I couldn’t compress at all. In Lori’s article, she talks about how compression isn’t always advantageous – especially over a LAN. Prior to reading the article, I really hadn’t considered all the information users were giving me and even better, that I could make decisions based on that information.

When a user visits a website, their browser sends a number of “HTTP-Headers” (An incomplete list). A great example of an HTTP Header, is “User-Agent.” In this header, the web browser informs the site it’s visiting what type of browser it is.

Google Chrome, for example, sends “Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.1 (KHTML, like Gecko) Chrome/6.0.428.0 Safari/534.1″

With this information, a website owner can decide to treat certain browsers differently than others.

An iPhone, for instance, might send something like”HTTP_USER_AGENT=Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1C25 Safari/419.3”

Some sites do an excellent job of leveraging this information to provide a better user experience. If you go to certain sites with an iPhone, you might notice yourself being redirected to, or or another “mobile-specific” site specially designed for a mobile device. Users obviously appreciate this since it keeps them from constantly having to zoom in and out and scrolling just to see the pages. While many companies create iPhone apps for situations like these, that doesn’t help people who have other mobile devices, hence the requirement for a mobile-specific site. One thing you’ll likely noticing when visiting mobile-specific sites is that it’s not simply the same content with a different resolution – it’s typically different menus, buttons, and fewer images. Since most iPhone browsing is being done via a cellular network, it’s good to consider latency as an experience inhibitor.

Using Lori’s example of providing compression only when it improves the user experience, we can apply the same logic to users with the iPhone user-agent header. On an F5 device, for instance, we’d create an iRule to be executed on HTTP_Request events that would look at the user-agent header and if it contained “iPhone,” we’d either send a redirect so the user would go to our mobile site, or compress data more aggressively, or even both. Using my own example of trying to compress data without causing issues for older browsers, I wouldn’t want to compress simply because a browser sent the “accept-encoding gzip” header – I’d really want to make sure I’m only compressing for user-agents I know can handle compressed data so it’d be a combination of both the “user-agent” and “accept-encoding gzip” headers. I often run into sites that, while being smart enough to detect my user-agent and make decisions based on it, provide a negative experience. For example, here’s the text I see when I navigate to a certain site using Google Chrome –

Please Upgrade Your Browser
To provide you with the most efficient experience, (removed)
utilizes advanced browser features of Internet Explorer 5.0 and greater.

Your Internet browser does not meet the minimum criteria.
Please download the latest version of Internet Explorer.

I’m obviously using one of the most capable browsers on the market, and this particular site not only says it won’t support me, but it also says I’d be better off with IE5. The only “saving grace” is that they provide a link through which I can download a browser they do support. Unfortunately, I’m stuck at this page and am not seeing any of their site’s content. Better behavior would be that I make it to their home page, am informed of the features the site doesn’t think I support, and can make a decision on whether I’d like to move forward. This site is obviously looking at the user-agent header, but is unfortunately making a blanket decision that because mine doesn’t contain IE, I’m not compatible. When this logic was written, Chrome didn’t exist. This behavior requires the logic to adapt constantly to new browsers. In this case, the site might be better off looking for headers that determine whether the browser supports the specific features required by IE.

Another interesting thought that popped into my head on the drive home yesterday was the type of inferences you can make about the person behind specific user-agents. If, for instance, I’m using Chrome to visit your site, I’m likely an advanced user who cares about new technology – do you really want to tell me that your site doesn’t support me and that I’d be better off with IE5? How about if I’m visiting your site with an iPhone – what does that say about me?

I’d love to see some of the analytics data comparing something like “conversion rate” for retail sites among different browsers. I imagine very few people purchase from their phone but I expect that quite a few of them are comparing prices – if that’s the case, it might make sense to have pricing readily available on your “mobile-specific” site.