Hacker News: tyler

New comment by tyler in "Making the Switch from Amazon Cloudfront to Fastly"

tyler — Tue, 31 Jul 2012 19:00:24 +0000

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

New comment by tyler in "Making the Switch from Amazon Cloudfront to Fastly"

tyler — Tue, 31 Jul 2012 08:05:50 +0000

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".

New comment by tyler in "Making the Switch from Amazon Cloudfront to Fastly"

tyler — Tue, 31 Jul 2012 07:28:26 +0000

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).

New comment by tyler in "Making the Switch from Amazon Cloudfront to Fastly"

tyler — Tue, 31 Jul 2012 07:11:49 +0000

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

New comment by tyler in "Making the Switch from Amazon Cloudfront to Fastly"

tyler — Mon, 30 Jul 2012 23:47:05 +0000

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.

New comment by tyler in "Making the Switch from Amazon Cloudfront to Fastly"

tyler — Mon, 30 Jul 2012 21:14:05 +0000

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.)

New comment by tyler in "Amazon CloudFront - Support For Dynamic Content"

tyler — Mon, 14 May 2012 12:16:54 +0000

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.

New comment by tyler in "Is Google (and mod_pagespeed) the Poor Man's CDN?"

tyler — Thu, 02 Feb 2012 17:57:05 +0000

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

New comment by tyler in "The condescending UI"

tyler — Fri, 09 Dec 2011 21:55:48 +0000

Cmd + `

New comment by tyler in "1,000,000 daily users with no cache"

tyler — Wed, 26 Oct 2011 09:46:56 +0000

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.

New comment by tyler in "1,000,000 daily users with no cache"

tyler — Wed, 26 Oct 2011 08:48:56 +0000

"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.

New comment by tyler in "Crustache is a fast C implementation of Mustache"

tyler — Mon, 29 Aug 2011 20:36:10 +0000

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

Parse Releases Their REST API

tyler — Mon, 22 Aug 2011 18:52:54 +0000

Article URL: https://www.parse.com/docs/rest

Comments URL: https://news.ycombinator.com/item?id=2913600

Points: 76

# Comments: 32

New comment by tyler in "BusinessWeek's Best Young Tech Entrepreneurs of 2011"

tyler — Tue, 17 May 2011 19:40:01 +0000

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

New comment by tyler in "Your Chrome browser might not be using HTTP anymore"

tyler — Wed, 04 May 2011 19:36:04 +0000

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.

New comment by tyler in "Weapons of Mass Assignment: Patio11 on Diaspora "

tyler — Wed, 27 Apr 2011 10:37:44 +0000

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.

New comment by tyler in "Weapons of Mass Assignment: Patio11 on Diaspora "

tyler — Wed, 27 Apr 2011 09:58:17 +0000

"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.

The Problem with Papers from Industry

tyler — Tue, 01 Mar 2011 21:13:46 +0000

Article URL: http://blog.codalism.com/?p=1386

Comments URL: https://news.ycombinator.com/item?id=2277224

Points: 2

# Comments: 0

New comment by tyler in "Spelling Corrector in 21 lines of Python "

tyler — Fri, 24 Dec 2010 02:35:09 +0000

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.

New comment by tyler in "To Trie or not to Trie – a comparison of efficient data structures"

tyler — Fri, 03 Sep 2010 00:26:07 +0000

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).