Re: Mars lander (Re: How to achieve application reliability)
On Sun, 05 December 1999, Nathan wrote:
Here is a great link explaining in detail the design and architecture of the web accelerators on the net that were designed to support the load that marspolarlander.com was supposed to generate.......although they have no feed to push....it was impressive.
Yes, it was very impressive. I was hoping they would be successfull, because in a few weeks the next event will also require some interesting web site hosting. If it had worked, then the people who follow could just copy it. Even without a feed to push, the sites were unresponsive for parts of the day. http://www.newsbytes.com/pubNews/99/140268.html I'm very concerned we still haven't proven we know how to handle big event sites on the Internet.
Not to harsh on the design at all, but is round trip time (the F5 solution) the best way to calculate which distributed hosting / caching site a client connection should go to? Variance in rtt from one trace to another, or variance in hop count from one trace to another, could lead to inconsistent balancing results as the client/server connection is going to be stuck in some kind of quasi-flow cache and additional requests forwarded from the client to the same server. Is it safer to use a bgp AS_PATH or MED over pure rtt? (granted, routes can flap and cause the same effect, but is it as much of a problem) Is anyone willing to share experiences with one or the other? Cheers. Travis ----- Original Message ----- From: Sean Donelan <sean@donelan.com> To: <nanog@merit.edu> Sent: Sunday, December 05, 1999 6:04 PM Subject: Re: Mars lander (Re: How to achieve application reliability)
On Sun, 05 December 1999, Nathan wrote:
Here is a great link explaining in detail the design and architecture of the web accelerators on the net that were designed to support the load
that
marspolarlander.com was supposed to generate.......although they have no feed to push....it was impressive.
Yes, it was very impressive. I was hoping they would be successfull, because in a few weeks the next event will also require some interesting web site hosting. If it had worked, then the people who follow could just copy it. Even without a feed to push, the sites were unresponsive for parts of the day.
http://www.newsbytes.com/pubNews/99/140268.html
I'm very concerned we still haven't proven we know how to handle big event sites on the Internet.
Yes, it was very impressive. I was hoping they would be successfull, because in a few weeks the next event will also require some interesting web site hosting. If it had worked, then the people who follow could just copy it. Even without a feed to push, the sites were unresponsive for parts of the day.
http://www.newsbytes.com/pubNews/99/140268.html
I'm very concerned we still haven't proven we know how to handle big event sites on the Internet.
performance of most of the mirrored sites of mars.jpl.nasa.gov, as well as: www.marspolarlander.com www.livefrommars.com www.planetary.org a few others i can't remember now was really, really bad most of the day. pulling up 300kb/s or even 28.8kb/s video from broadcast.com was horrible with several minutes time to "sync" with nearly still control room video. (i'm blaming sites as opposed to network because pings and traceroutes really didn't look bad at all from where i was sitting) i had really expected they prepared for this in a big way. if nasa had gotten contact the first time and actually had video, stills, and audio to distribute, i personally believe it would have all melted down. i don't think it was so much network problems as server/web/application problems. pages came up blank many times, servers said "too may users", etc. i think we haven't proven we know how to handle server/os/application development on the net as opposed to networks that scale. -brett
participants (3)
-
brett watson -
Sean Donelan -
Travis Pugh