tyler

95% of requests. But yeah! And thank you. :)

TTFB at the 50th hovers around 175 microseconds, 75th is at 250 microseconds, 95th around 450 microseconds.

As for the purging stuff, I do mean cross-region. So, it depends upon which node receives your purge request. 150ms is average, but really it's "network latency plus a millisecond or so".

We like to think that the exact number of requests is less important than exactly how they're handled. While it would be cool to go "we serve a billion requests a second", we're still an early stage startup. We're spending more time making our responses even faster (< 1ms on the 99th percentile) and trying to provide things that no one else does (for instance, instant purging and surrogate key purging).

I'm sorry that my statement is bothering you. I'm going based on numerous conversations with people considering using Fastly. It's quite possible that I have a skewed sample, however I'm not intentionally spreading FUD, for what that's worth.

See: http://en.wikipedia.org/wiki/Hanlons_razor

Alright. Let's go point-by-point.

The primary feature advertised on fastly's website is a feature every real CDN (as in, "not CloudFront") offers: an API to immediately purge your content.

Every CDN offers a mechanism to purge content, but they are not immediate. Edgecast takes up to 15 minutes, CDNetworks I've seen take 20, Cloudfront can take as much as 30. When we say immediate, we mean really immediate. Generally speaking, it takes about 150 milliseconds.

Meanwhile, their bandwidth pricing is insane (albeitimilar to CloudFront): their $/GB is a few times what I'm paying for a "real CDN", and is about what you will get if you call Akamai and then don't negotiate.

Obviously, we will negotiate as well when we're talking about significant amounts of traffic. And good luck getting Akamai to call you back if you don't have significant amounts of traffic.

The real question is: how many points of presence do they have? CDNetworks has over a hundred, and Akamai has over a thousand. Are we talking "even smaller than CloudFlare" here? (Apparently, the answer is "yes: even smaller, they only 7".)

Yep. That's true. We're a rather young company and are actively expanding. However, what is most notable about this is that despite having far fewer pops, we're still significantly faster than most other CDNs, especially in major population centers. We've put a ton of work into reducing latency inside our servers so as to make better use of the pops that we currently have.

Actually, tests from us and several of our customers have shown us significantly faster than Edgecast throughout the US and Europe. (I work at Fastly.)

If that's what you're after you might want to check out Fastly. We're a CDN entirely based on Varnish, with all the features that implies.

Fastly (fastly.com) is designed for exactly this purpose.

Cmd + `

No. Memcached on a reasonable server will do millions of requests per second. 50,000 updates per second is nothing for any modern cache.

Also, replication has nothing to do with whether or not "without a cache" is a meaningful statement. The point is that by holding their entire data set in RAM, they've nullified the need for a cache. Effectively, their database is their cache.

And considering the data isn't even written to disk for about 15 minutes, it's really more cache than database anyway.

"with no cache" is a bit of a misleading statement, considering the entirety of their data set is stored in RAM. Turns out you don't really need memcached if you don't read anything from disk.

I had a little project a while ago that compiled Mustache templates into C. Never was completely done, but it mostly works: https://github.com/tyler/speed_stache

Greplin has to do huge scale information retrieval. This probably counts as engineering. (See: SIGIR)

I don't mean to be pedantic, but the word "transparent", in this context, means "easily perceived or detected". I believe you're using it to mean the opposite.

So, what the "thread-safe mode" does is enable threads in Rails. (i.e. one thread per request.) To my knowledge, it does not switch out thread-unsafe code for thread-safe code.

Moreover, it's irrelevant. As I mentioned, this is unrelated to why Rails apps are typically run as multiple processes.

"Since Rails is not threadsafe, typically several processes will run in parallel on a machine, behind a threaded Web server such as Apache or nginx."

This is incorrect. Rails 3 (and 2.3) are thread-safe. They typically run in multiple processes because of Ruby's GIL.

It sounds like you're conflating two techniques here. The first (as others have mentioned) is cosine similarity, which measures the angle between the vectors. However, the bit about 0s and 1s sounds like you're talking about locality-sensitive hashing (http://en.wikipedia.org/wiki/Locality_sensitive_hashing). LSH is often used to estimate cosine similarity, as cosine similarity can be quite expensive to calculate. I know Google and others are using it for such.

Two useful implementations that this article misses are Array-compacted tries (aka dual-array tries) and Array-mapped tries. ACTs are nice due to the small memory footprint and good cache-locality, but have the downside of being difficult and time-consuming to construct. AMTs have a bit-array for determining existence of children and a sorted array of child-pointers in each node and are surprisingly fast at both insertion and search. Both have been described elsewhere, but I like the explanations by Phil Bagwell in his paper, "Fast And Space Efficient Trie Searches" (1998).

The actual blog post: http://conversations.nokia.com/2010/06/28/how-do-you-hold-yo...

I think that rather than a simple "I will ignore X", his point was more "I will ignore X because experimental evidence indicates X is not true". This seems completely legitimate to me.

This article is poorly written and flat out wrong. His second example simply shows a public post of his on a public group. His statement "Facebook makes public EVERYTHING about its users via its search API" is just incorrect.

But of course, it's filled with lots of capital letters, so he must be right.

That was very carefully crafted in order to not answer the question at all. Nicely done.

You say "any changes would have to be carefully considered". So, are said changes being considered or are they not?

That's an understatement.

So, it turns out that the version of Mobile Safari on the iPhone doesn't support getBoundingClientRect, which we were relying on. The fix for that should go out soon, at which point it will work on your iPhone.

All of them. :)

Not that I'd actually recommend doing it, but I'd bet that technique does work some small percentage of the time. What does Facebook have to lose by seeming desperate at that stage? I think it's smart.

We've talked about doing both of those things. They're high on my to-do list.

And of course, you know that users won't see any difference or care, despite never having seen, let alone used it. Just because you think the problem has been solved well enough, doesn't mean everyone does. After all, who needs a refrigerator when you have an ice box?

We create basically the same experience across browsers, but use the latest tech that the browser supports. For instance, things will render much faster in Chrome than in IE6.

However, the documents will basically look the same across all of our supported browsers.