<story><title>Porting dl.google.com from C++ to Go</title><url>http://talks.golang.org/2013/oscon-dl.slide</url></story><parent_chain><item><author>joebo</author><text>I don&amp;#x27;t understand the need for the payload server from the slides. That makes me wonder - why not just use a HTTP server to serve the static files (e.g. nginx)? I&amp;#x27;m sure I&amp;#x27;m missing the obvious, but I&amp;#x27;m probably not the only person wondering it.</text></item></parent_chain><comment><author>evmar</author><text>It appears from slides 14, 21, and 24, that copying all of the static files that needed be served onto a single machine could take over 12 hours.  Another way to say that is that the totality of content that is served from that single host is too large to put on a single machine.  The &amp;quot;groupcache&amp;quot; abstraction lets the http-serving machines dynamically serve the hot subsets of the larger file set (represented by &amp;quot;storage svc&amp;quot; on slide 55).</text></comment>
<story><title>Porting dl.google.com from C++ to Go</title><url>http://talks.golang.org/2013/oscon-dl.slide</url></story><parent_chain><item><author>joebo</author><text>I don&amp;#x27;t understand the need for the payload server from the slides. That makes me wonder - why not just use a HTTP server to serve the static files (e.g. nginx)? I&amp;#x27;m sure I&amp;#x27;m missing the obvious, but I&amp;#x27;m probably not the only person wondering it.</text></item></parent_chain><comment><author>awj</author><text>From the looks of it, they wanted support for putting files in place before a release date and easy per-file header&amp;#x2F;caching&amp;#x2F;access control. Add in a few other miscellaneous features &lt;i&gt;and&lt;/i&gt; make it available to everyone and you&amp;#x27;re at a point where an HTTP server probably won&amp;#x27;t cut it.</text></comment>