3 ms·
Here using Fastly with great results. Consistently fast, including SSL negotiation. Truly fast invalidation. A ton of control available with Custom VCLs (they r
by astral303 11y ago
Here using Fastly with great results. Consistently fast, including SSL negotiation. Truly fast invalidation. A ton of control available with Custom VCLs (they run a custom Varnish version). E.g. you can generate an "Expires:" header automatically on the CDN edge based on the Cache-Control header. You can serve a static resource if the backend times out. Best of all stale refresh and soft purge means that you can update resources "in the background" on the CDN and avoid exposing your clients to "miss latency" (backend server latency).
I feel that the ultimate answer is a multi-CDN solution. If your assets are critical to be always available, I think you are going to want to diversify your CDNs. The challenge comes in how to load balance and/or failover across CDNs--whether that's easy or not depends on your use case. Doing so automatically at the time of trouble is a challenge too. Dyn just rolled out a product called Internet Intelligence that monitors all the CDN's performances (with end-user perf measurements) and can help you determine whether one of your CDNs is slow (and whether it's slow only in certain parts of the world). Theoretically, then you can combine geo-aware DNS with congestion-aware CDN selection and BAM, diversified, less-congestion-sensitive content delivery.
- boundlessdreamz 11y agoMy experience with fastly as an end user is not great. rubygems is hosted with fastly and it times out a lot on some PoPs (singapore). Also fastly has per request pricing which is something I want to avoid. Another multi CDN solution is from cedexis - http://www.cedexis.com/openmix/multi-cdn.html http://www.cedexis.com/openmix/multi-cdn.html
- jamescun 11y agoMy faith in Fastly was shaken after earlier this year, we experienced connections intermittently failed (HTTP 5xx) to any service behind Fastly (ours and third party) in our Amsterdam datacentre. We contacted their support but told us repeatedly it must be our fault (like a proxy). Long story short after investigation it was confirmed to be their fault and most likely a machine-gone-bad in their PoP and the intermittent nature was related to balancing across them. This was not resolved until their team woke up and we pinged their team on IRC. It shook my support from the obvious lack of monitoring or on-call system.