With GZIP compression, bandwidth drops but more importantly load times can decrease significantly. "It takes several round trips between client and server before the two can communicate at the highest possible speed [and for broadband users] the number of round trips is the larger factor in determining the time required to load a web page". There was a graph depicting the non-linear impact file size increases have on load times but I can't find it... =[
In the Google article on compression, a 175% increase in a page's size (non-GZIP version of Facebook.com) results in a 414% increase in load time on DSL. Load time does not increase linearly with file size and hence why GZIP compression is so important for performant websites!
You just need to configure your origin servers to serve GZip even to HTTP 1.0 (which is what CF requests will come as) and set the "Vary: Accept-Encoding" header to prevent users of old IE versions from having GZip'd content they don't support stuffed down their throats.
For example, this is my nginx configuration which serves both GZip'd and non-GZip'd versions of the same objects via CF. The second and third lines are the most important for correct AWS CF GZip distribution:
gzip_disable "MSIE [1-6]\.";
To clarify the original comment: I think it's rather pointless to gzip a PNG file, since PNG files use deflate compression, the same method gzip uses, and hence it has very little real benefit, if any.
Also, I don't think your link relates the the comment. Your link is about choosing between gzip and deflate; the comment you found objectionable was about the irony of gzipping a file that is in a format that also support deflate (so you might compress a compressed file; which I think can actually make the file larger).
Addressing your second point: I also thought the comment was a snarky reply, wondering why someone would use gzip instead of deflate. The parent comment addressed, specifically, why they were using gzip on PNG, which is why I assumed the 3 character response was focused on the compression type, rather than whether to use it on PNGs.
Right now I'm proxying image requests to s3 through nginx, which is a terrible workaround.
The AWS forums has a topic on the issue started in 2009 (~200 replies so far...): https://forums.aws.amazon.com/thread.jspa?threadID=34281
S3 has eleven nines of durability.
In reality, neither you, nor Amazon, nor anyone else has any idea how durable S3 is. But if they _did_, it wouldn't matter because unexpected interactions, cascading failures, and SNAFU will keep it from ever being realized.
Much better to have more frequent, very boring failures than to have rare spectacular ones.
Durability means you will get your data eventually (it will not be lost). Availability means you will get your data right now, which is probably what he really cares about in terms of serving live internet traffic.
Put another way: S3 not infrequently has availability hiccups (files are temporarily unavailable, resulting in a disruption of service), without taking durability hits (your files haven't been lost, you just can't see them right now).
there are many other product features that EC2/R53/ELB/etc could use, but calling this AWS is a little too broad.
Also AWS is an organization (part of a larger organization), but S3 is a product.
Am I missing something here? Your fonts were going to be in a separate file anyway, right?
One example of how fundamental this is: you cannot currently perform a direct AJAX upload to an s3 bucket from a web application hosted on an ec2 instance.
There is a postMessage hack that will work with small files, and of course you can use a proxy, but you'd think it would be a common scenario to want to upload files directly to S3.
I only wish someone from the S3 team at Amazon would at least answer to this thread:
Hundreds of messages in this thread and no answer after 2 years and counting.
2.) AWS have always been awesome at responding to customer feedback in my experience
3.) But you're right, except change "is going" to "has gone". A friend of mine who works in SEO and social media (the good kind) says "In 2009 companies needed to have social media accounts, in 2010 they needed to put out content on them, in 2011 they needed to respond to customers through them" and he's right. The mentality of customers of Twitter/Facebook has, for the most part, moved from "holy hell, a company ACTUALLY SAW MY TWEET?" to "I tweeted about my problem an hour ago, where the fuck is my answer?".
Can anybody else verify this? To me, it seems ridiculous that anybody would expect to get support by posting something to a random website. Personally, I go to twitter.com about four times a year and type in the names of my products to do a quick vanity search about what people are saying about them. I've never seen anything like a support request (or even a complete coherent thought) in there. It just doesn't seem like something worth monitoring.
My product sites all have a contact page with an email address on it. If you want to contact me, that's how you do it.
Amazon has forums with dedicated representatives monitoring them. That's how you get in touch with them. I've never gone more than a few hours without a response from somebody who knows what they're talking about in there.
This is basically because plenty of companies are doing this (see https://twitter.com/#!/vodafoneuk for example), so people get used to it.
So really it's not so much posting to a random website, it's more using social media as a means to contact them.
But based on the trend, people have come to expect it as the norm thanks to companies that lead the way in doing it, and now those compares are leading the way in proactively reaching out to customers who tweet not directly at them - for example 9 months ago I tweeted something like "As soon as my contract with Vodafone ends I'm moving to Orange", both companies tweeted at me offering to help - so people could well come to expect that as the norm too.
This cracked me up. And likewise, I think we've seen one. Meanwhile we have nearly a quarter million email "tickets" to date.
Lots of users realize that there is likely a faster response from twitter than email@example.com because the developer has some amount of face at stake with the dirty laundry in public.
If you really wanted to "expose" something in public, you'd put it up on a blog or someplace that's actually on the public facing internet. Not that it would get you any more chance of the company hearing about it, but at least other people might see it.
And, of course, if you run a company that simply doesn't respond to things on Twitter, the customer in question will hopefully learn that they can send you an email and get a fast response.
Fortunately it looks like AWS is starting to use JSON for newer APIs: http://docs.amazonwebservices.com/amazondynamodb/latest/deve...
In the forums, an Amazon rep promised it'd be available within 2011. No luck, though.