igrigorik

I linked to Will's post in the article, definitely worth a read: https://plus.google.com/103382935642834907366/posts/FKot8mgh...

Check the comments, there are some very good discussions in there with Daniel Stenberg about c-ares and other resolvers.

Just tested it in Canary builds and the async DNS resolver does parse and respect /etc/hosts.

Yup, we can do that too! I didn't mention it in the writeup, but you can also insert <link rel="dns-prefetch" href="http://www.domain.com/>; hints into the head of the document to tell the browser to pre-resolve certain domains.

An often overlooked reason for supporting this is to pre-resolve hostnames behind a redirect. If you have a "http://a.com/resource, which redirects to "http://b.com/resource, and you know this relationship while you're generating the page, then injecting a dns-prefetch link can help hide the cost of the extra DNS lookup when the browser is following the 3xx.

To the contrary, the tools are getting progressively worse. Show me one feature in Powerpoint or Keynote that is specifically designed to give me actionable feedback on how to improve my presentation.

I'm not arguing for or against visual design - yes, you're right nothing new there. What I'm trying to point out, as we start migrating our presentation tools to the web, is that we don't need to copy all the useless inheritance.

For now, and yes I'm the early technical adopter.. I'm willing to edit the HTML markup directly, heck I'll FTP the darn thing to your server, and will do other backflips.. all if you manage to give me good feedback on how to do a better presentation next time around.

An erlang process has a global PID, a ZeroMQ socket has an address - same difference. If you want, you can run everything over named pipes, UDP, TCP, or via an in-memory transport with ZMQ and achieve the same semantics. Case in point: there are plenty actor libraries built on top of ZMQ.

You can run ZMQ devices which can act as routers, and you can easily create fan outs, fan ins, pipelines, and more.

For a mildly interesting example of building a "dynamic" typology, check this experiment: https://github.com/igrigorik/zeroconf-router

Contrary to what the author says, ZeroMQ is actually a very good and powerful tool for building dynamic topologies - no idea why he decided that it biases your design towards a "static" network.

As a preview, here's a quick spreadsheet I pulled with a few stats for month of April (via BigQuery): http://bit.ly/github-bigquery

- 5.8M events in April

- Most popular languages? Javascript, Java and Ruby.

- Most popular new repo? Prince-of-Persia-Apple-II

- Most watched repo? meteor

If you want, you can also access the raw archives, see instructions on githubarchive.org

Why are we slow? An average page weighs in at ~1MB: http://bit.ly/IRUzXD - 60% images, 18% JS, and a touch of html. Yikes.

As in, served through Github's CDN (akamai)? Google's App Engine has a few GFE's around the world as well.. :)

For the HN audience you probably could, since we're all on modern browsers. The pattern above is what GA uses to guarantee most consistent behavior across all browsers. It comes down to browser support for the async keyword: http://stackoverflow.com/questions/1834077/which-browsers-su...

As far as async vs. defer, here's a good summary: http://www.sitepoint.com/non-blocking-async-defer/

GA instrumentation should be in place now. Go into GA > Traffic Sources > Social Plugins, and you should see it there. (don't forget to change the date range)

The data is coming from thrifdb API (like all other buttons), so there is a small delay in the "true count" and what gets displayed in the button. From what I can tell, its ~within minute(s) accuracy.

That's a good idea. Ideally a combination of time and points actually: if it's a new article then show the counter, but if its older and low points, then hide the button.

Working on auto-instrumenting the button with Google Analytics trackSocial stuff - stay tuned.

Most Google pages do load in much less than 500ms - of course, the trick here is what you have in mind by "load". The actual slow renders are all on browser (read, javascript) side: mobile clients, etc.

As far as best practices, I agree we need to do a better job of advertising this material. It is available:

https://developers.google.com/speed/docs/best-practices/rule... https://developers.google.com/speed/docs/insights/rules

In fact, this entire site is worth spending some time one: https://developers.google.com/speed/

nginx support is in the works and I'm hoping we'll see something public in first half of this year. The apache module also got a lot of love recently, so definitely check it out.

Dev wise, probably the biggest hurdle for most people today is simply installing the latest SSL builds for NPN support (usually entails recompiling your favorite language against it as well).

http://www.chromium.org/spdy - contains some great and in-depth research motivating SPDY.

Original whitepaper: http://www.chromium.org/spdy/spdy-whitepaper

Here's a good tech talk to checkout as well: http://www.youtube.com/watch?v=TNBkxA313kk

Draft 3 has also updated the dictionary, here's the research paper motivating the change: http://www.eecis.udel.edu/~amer/PEL/poc/pdf/SPDY-Fan.pdf

With long-polling you have reconnect after every message, which is a very expensive operation (relatively speaking). HTTP headers often form the bulk of the request, and the number of connections you have to maintain is high. All of these things add up.

In addition, TCP slow start, window sizing, etc, work against you when it comes to optimizing for latency: http://www.igvita.com/2011/10/20/faster-web-vs-tcp-slow-star...

TCP is a transport layer and we're not talking about replacing TCP - not going to happen, and no reason to do that. 0MQ, SPDY, etc, run at application layer, and TCP flow control, window sizing, etc, work in tandem with the application layer controls.

Right, I'm not linking SPDY and "dynamic topologies". Rather, I'm linking the message-oriented communication of SPDY and 0MQ (and 0MQ is not the only way to achieve this).

Once a request enters your "back office" it should all be message oriented, over persistent connections, with flow control / QoS, and the like.

WebSockets is not a replacement for HTTP/SPDY. Don't forget that a WebSocket is effectively an upgraded HTTP / SPDY connection (in fact, there is work in progress to enable WS over SPDY).

In many cases, you don't need bi-directional communication.. Which is also why HTML5 spec introduced Server Sent Events (SSE): http://www.igvita.com/2011/08/26/server-sent-event-notificat...

I think it's worth mentioning that MySQL has a nice collection of UDF's to handle JSON object output, arrays, and so on: http://www.mysqludf.org/lib_mysqludf_json/index.php

Alex, do you know if Mongrel2 have any interesting production deployments? In terms of visibility, throughput, or any other metrics. Outside from the architecture discussions, I haven't see any mentions of it.. (and I'm a fan of the architecture).

Sinatra-synchrony is awesome. For those looking to do a few more advanced use-cases, like HTTP streaming upload/downloads, websockets, etc.. Take a look at Goliath: https://github.com/postrank-labs/goliath

Same idea, em-synchrony under the hood.

https://github.com/igrigorik/bugspots - for anyone that's curious to try it on their own git repo.

(improvements welcome! :-))

New version of bloomfilter.rb uses SETBIT/GETBIT: https://github.com/igrigorik/bloomfilter-rb/blob/master/lib/...

The "bit" per key was prior to setbit/getbit functionality. The new implementation is, in fact, very efficient.

For good data and research on this topic, check the work done by the SPDY team (I linked it in the article, but its easy to miss):

http://docs.google.com/a/chromium.org/viewer?a=v&pid=sit...

http://www.chromium.org/spdy/An_Argument_For_Changing_TCP_Sl...

As for slow-start question: CWND is set on the server (on the sender side). You can increase your advertised window, but that will have no effect since it's the server that ramps up the bandwidth, not the client.

If you do control both the server and the client then you will definitely see a difference.

AFAIK, Hadoop is converging on Avro -- not sure about the state of each component within Hadoop with respect to avro, but in long term, I expect it will be the protocol.

Ah, interesting -- is this documented anywhere? I did see mentions of Chrome downgrading background tabs, but did not find any specific numbers.

We've suspended new signups for the moment, while we figure out what lies ahead. Having said that, for all existing users, the service will continue as is! Stay tuned for more.