Domain: speedera.com
Stories and comments across the archive that link to speedera.com.
Comments · 23
-
Past viewer statisticsI work for Speedera, the delivery network NASA uses for its main NASA TV live streaming link and the HTTP caching for its major web sites. So you are right that assuming bandwidth isn't going to be a problem. Its just that NASA has to pay for these services and unlike TV, the more people that watch, the more they have to pay.
For some statistics here's some press releases and my previous posting.
-
Past viewer statisticsI work for Speedera, the delivery network NASA uses for its main NASA TV live streaming link and the HTTP caching for its major web sites. So you are right that assuming bandwidth isn't going to be a problem. Its just that NASA has to pay for these services and unlike TV, the more people that watch, the more they have to pay.
For some statistics here's some press releases and my previous posting.
-
Re:How do NASA's needs compare to other high bandw
-
Re:Akamai is your friendThe original article says: We don't really stand to make any profit so we can't put a huge bankroll on this project, but we would like to have it up for holiday goodwill. That probably rules out Akamai. They seem to enjoy their reputation for having the highest priced bandwidth.
One way you can still make use of commerical Content Delivery Networks (CDNs) is by using refer blocking or a secure download service, where the file will be delivered from the CDN only by use of a time-expiring URL from your site. That way you can ensure that the media is only viewed from your site's pages and you can captitalize on any advertising. If you move beyond Shockwave and to Flash, then Speedera is the only one of the other CDNs mentioned above that has annouced streaming from Macromedia's Flash Communications Servers.
You needed be concerned about the slashdot effect with Speedera. I've seen many Slashdot articles that link to media hosted on Speedera e.g., NASA stories). They turn out to be smaller blips that the corresponding surges from TV other major portals like Yahoo and MSN. Here's an example.
Disclaimer: I work for Speedera Networks, Inc.
-
Re:Whatever happened to your decentralized net?
And as always, there is a more-than-viable alternative: http://www.speedera.com
(yes, i work there) -
Re:Time to check out other providers.
Actually last month's flop was not a DNS issue, but it did effectively shutdown websites also for one and a half hours.
And if we're pushing dual sourcing don't overlook Speedera. You can even see today's outage on the Speedrank performance page. BTW, C & W USA declared chapter 11 a while ago and got aquired by Savvis. Seems like they change company name every couple of years.
-
Re:Time to check out other providers.
Actually last month's flop was not a DNS issue, but it did effectively shutdown websites also for one and a half hours.
And if we're pushing dual sourcing don't overlook Speedera. You can even see today's outage on the Speedrank performance page. BTW, C & W USA declared chapter 11 a while ago and got aquired by Savvis. Seems like they change company name every couple of years.
-
Re:Apple down, Microsoft up
-
Re:Apple down, Microsoft up
-
Re:I'd say it's near a natural monopoly...
There are competitors to Akamai. One is Speedera, who are much cheaper. Of course, they allegedly achieved this by stealing Akamai's trade secrets.
-
Re:Ah, knee-jerk reactions.
> I love how the first reaction when something goes wrong is to replace it, or introduce competiton, or whatever. Yes, there are plenty of times when a service needs competition to encourage it to suck less. But go find me another company that is even remotely prepared to do DNS load-balancing. Verisign? Oh, that's a great idea. Going to start one yourself? Let us know when you have the infrastructure.
*ahem* Speedera Networks -
Better alternative
one word: Speedera. I've used both Akamai and Speedera, and Speedera has better service, better tools, better people to deal with, and much better prices.
-
Re:Akamai is still losing money
Speedera, for one.
-
Re:Can we set up a competition? Can it be measured
"A NASA guy [That was me, but I don't work for NASA directly, but for Speedera who delivers their traffic] says
... Slashdot was a drop in the bucket compared to links from mainstream news web sites". I said it here. The Slashdot load depends on the size of the objects downloaded of course, but a reasonable generalization is that the traffic from a top 10 portal is about five to ten times higher. -
Re:NASA isn't concerned with being slashdotted theNo they're not.
I work at Speedera who is delivering their content and NASA TV. At 6pm EST when slashdot posted this story the traffic increased only about 100Mbps. Articles posted on AOL, MSN and Yahoo home pages increase the traffic much more. The NASA TV live stream when Opportunity landed was 4 Gbps. There are lots of other sources that are bigger than the slashdot effect.
See the press release for more details on the traffic and our SpeedRank index for historical performance and availabilty of NASA's site.
-
Re:NASA isn't concerned with being slashdotted theNo they're not.
I work at Speedera who is delivering their content and NASA TV. At 6pm EST when slashdot posted this story the traffic increased only about 100Mbps. Articles posted on AOL, MSN and Yahoo home pages increase the traffic much more. The NASA TV live stream when Opportunity landed was 4 Gbps. There are lots of other sources that are bigger than the slashdot effect.
See the press release for more details on the traffic and our SpeedRank index for historical performance and availabilty of NASA's site.
-
This is not "Tranparent Web Caching"
The generally accepted term for this type of technology is "Content Distribution Networking" or "Content Delivery Networking". Akamai, Speedera, Digital Island etc. are Content Distribution companies which will (according to the necessary commercial agreements), take a customer's content and distribute it around their overlay CDNs. Generally speaking, these CDNs overlay the traditional Internet using co-located space in customer or exchange point datacentres. There are, however, some CDN organisations who take the approach of building their own infrastructure.
"Transparent Web Caching" on the other hand is generally a term applied to the transparent redirection of TCP port 80 IP traffic on access equipment through a set of HTTP proxy devices. This technique is used by many ISPs to force users to use their Webcaches even if the user thinks they are being clever by disabling the pre-defined HTTP Proxy settings in their Web browser.
Until recently, you could build your own CDN ($$$) using software from people such as Inktomi, but can still use devices from other manufacturers such as Network Appliance or Cisco Systems.
-
Re:Content Delivery Network
My employer is looking at CDNs. I understand that they had an impressive presentation from Speedera as well. It looks like Speedera has a service specifically for downloads.
No, I didn't site through the presentation; however, our admin guys seemed impressed. Just another option. -
Re:Content Delivery Network
My employer is looking at CDNs. I understand that they had an impressive presentation from Speedera as well. It looks like Speedera has a service specifically for downloads.
No, I didn't site through the presentation; however, our admin guys seemed impressed. Just another option. -
Re:Duh...Ever heard of Akamai?leviramsey writes:
Yeah, but afaik, akamai doesn't cache the actual html pages, just flash, images, videos, and so forth. Kinda difficult for those to be useful when no one can get CNN's index.html file, eh?
I don't know about Akamai, but other CDN's such as my employer, Speedera Networks, can cache HTML pages. We can even provide the raw logs back to content provider so you don't lose your statistics. E.g., we do this for the PGA, HP, our own page www.speedera.com and some news portals.
As for CNN on Sept 11th, they never delivered their HTML base page via a CDN which would have made for seemless handling of the traffic. But instead they solved the immediate congestion problem (after 3 hours and 40 minutes) by creating a single stripped down static page that used fewer resources for the site. Here is a timeline of the www.cnn.com home page as seen by our Site Analyser service.
- 08:50 EDT - Base page errors started occuring, presumably due to lots of requests generating a too high load on CNN's servers. This resulted in end users not being able to see any of the site's content.
- 12:00 to 13:30 - Base page errors fluctuate with embbeded content errors and a few seconds of DNS response time to 205.188.214.121 which nslookup calls tswebsys2.ptn.aol.com
- 13:30 - Successfull, sub-second delivery of a stripped down 2915 byte index.html page from www.cnn.com with only single 14144 byte image from akamai.net.
- 08:50 EDT - Base page errors started occuring, presumably due to lots of requests generating a too high load on CNN's servers. This resulted in end users not being able to see any of the site's content.
-
Re:Duh...Ever heard of Akamai?leviramsey writes:
Yeah, but afaik, akamai doesn't cache the actual html pages, just flash, images, videos, and so forth. Kinda difficult for those to be useful when no one can get CNN's index.html file, eh?
I don't know about Akamai, but other CDN's such as my employer, Speedera Networks, can cache HTML pages. We can even provide the raw logs back to content provider so you don't lose your statistics. E.g., we do this for the PGA, HP, our own page www.speedera.com and some news portals.
As for CNN on Sept 11th, they never delivered their HTML base page via a CDN which would have made for seemless handling of the traffic. But instead they solved the immediate congestion problem (after 3 hours and 40 minutes) by creating a single stripped down static page that used fewer resources for the site. Here is a timeline of the www.cnn.com home page as seen by our Site Analyser service.
- 08:50 EDT - Base page errors started occuring, presumably due to lots of requests generating a too high load on CNN's servers. This resulted in end users not being able to see any of the site's content.
- 12:00 to 13:30 - Base page errors fluctuate with embbeded content errors and a few seconds of DNS response time to 205.188.214.121 which nslookup calls tswebsys2.ptn.aol.com
- 13:30 - Successfull, sub-second delivery of a stripped down 2915 byte index.html page from www.cnn.com with only single 14144 byte image from akamai.net.
- 08:50 EDT - Base page errors started occuring, presumably due to lots of requests generating a too high load on CNN's servers. This resulted in end users not being able to see any of the site's content.
-
Re:Duh...Ever heard of Akamai?leviramsey writes:
Yeah, but afaik, akamai doesn't cache the actual html pages, just flash, images, videos, and so forth. Kinda difficult for those to be useful when no one can get CNN's index.html file, eh?
I don't know about Akamai, but other CDN's such as my employer, Speedera Networks, can cache HTML pages. We can even provide the raw logs back to content provider so you don't lose your statistics. E.g., we do this for the PGA, HP, our own page www.speedera.com and some news portals.
As for CNN on Sept 11th, they never delivered their HTML base page via a CDN which would have made for seemless handling of the traffic. But instead they solved the immediate congestion problem (after 3 hours and 40 minutes) by creating a single stripped down static page that used fewer resources for the site. Here is a timeline of the www.cnn.com home page as seen by our Site Analyser service.
- 08:50 EDT - Base page errors started occuring, presumably due to lots of requests generating a too high load on CNN's servers. This resulted in end users not being able to see any of the site's content.
- 12:00 to 13:30 - Base page errors fluctuate with embbeded content errors and a few seconds of DNS response time to 205.188.214.121 which nslookup calls tswebsys2.ptn.aol.com
- 13:30 - Successfull, sub-second delivery of a stripped down 2915 byte index.html page from www.cnn.com with only single 14144 byte image from akamai.net.
- 08:50 EDT - Base page errors started occuring, presumably due to lots of requests generating a too high load on CNN's servers. This resulted in end users not being able to see any of the site's content.
-
Re:Why web bugs are particularly eviltbo writes: Web bugs are more evil than your average URL link because you have to click on the link, whereas a web bug (and the potential attached evil code) gets loaded automatically if you have an HTML-enabled mail viewer Yes, downloading URLs without user involvement is evil. Part of the problem are the email clients that default to rendering message bodies of the first unread message and not asking the user to confirm remote image downloads. (E.g., Netscape Messaenger and MS Outlook, but - I think - not AOL 6.0 and others reported by other slashdot posters.) Again this is a security vs convinence tradeoff.
2) Automatically executing code from a remote, untrusted source is bad, kids. I haven't seen a web bug that actually executes remote code on the local client machine unless you consider JavaScript code to be unsafe. Sure JavaScript can be unsafe if your browser's intepreter has an implementation bug or you consider certain information like screen resolution, local timezone and other browser options to be private, but we are not talking virus risk here.
The Web Bug FAQ for more information. In particular note that it does list some non-evil uses for web bugs:
Another use of Web bugs is to provide an independent accounting of how many people have visited a particular Web site.
Web bugs are also used to gather statistics about Web browser usage at different places on the Internet.
E.g., If you want your site to run at the fastest posible speed, you might host static HTML with a globaly traffic managed web caching or hosting company like Akamai or Speedera But you still would like to get logs directly for anaylzing traffic to your site and comparing with the web hosting company's bills. So you place a web bug on your pages directly back to your origin site (or third party like LiveStat). The user experence is still fast if done right, because the slow logging to your server occurs after the page is rendered.