igrigorik

I see your point, but I'm not convinced that the amount of data (raw volume size) and the read speeds of flash lead to the same behavior as shaders + GPU. GPU's are processing an order (or several) of magnitude more data, which makes shaders a useful feature: data and computation locality.

Flash is 10x slower than RAM (in an ideal case), and even then, we haven't had the need to introduce 'shader like' features into RAM - yes, because historically we haven't stored all that much in it, but even with modern 64Gb configurations, same thing...

Well, if an average random access to disk is ~5ms, and an X25 Intel SSD is ~500 microseconds, then we're already talking a 10x difference and that's for a 'consumer grade' SSD. I'm sure the latency will come down over time as well. If you look at some of the PCI-E SSD solutions, then we're dipping below 100 microseconds, which means we're into 50-60x difference.

Huh, interesting. Any resources where I can learn more about these firmware optimizations? Intuitively, that doesn't make much sense: it would seem that dropping a lot of the software overhead associated with concurrency, etc, would yield a significant improvement.

Having said that, it's also possible that the actual 'software overhead' is pretty much negligible when compared to disk access times.

Would love to learn more on this.

Oi.. One day, I'll get around to fix that. :-)

Great way to kill the momentum and innovation. The only reason Ruby is still relevant today is directly due to its dynamism and continuous evolution. If Python declares a moratorium, they'll be shooting themselves in the foot.

Fixed, ty!

And plugins! I didn't talk about it because there is not much to show at this point, but the BQL plugin is a great example of what's possible. I fully expect that plugins will be the next big thing for RabbitMQ.

RSSCloud or not -- I do happen to think that we need a push RSS solution -- what really bugs me is the fact that once again, we're inventing different standards to do the exact same thing. As if ATOM vs RSS wasn't enough, now we have RSSCloud + PubsubHubbub to worry about. PSHB already has Google behind it (all of Feedburner feeds support it), so I really fail to see what wordpress won by adopting RSSCloud.

Besides, while Dave is a brilliant guy, PSHB already has a lot more people working on it with open source hub and client implementations (heck, I wrote one for Ruby!).

Same post, different URL, but with a lot more comments & discussion: http://orion.heroku.com/past/2009/7/29/io_performance_on_ebs...

(bah!)

So is the source behind HN available somewhere? Would love to setup it up for other verticals...

great tips, kudos!

Hmm, that sounds like a bug. Do you see any content on this page: http://postrank.com/feed/2720a6fc8fb2e4b346715972c954fe7a

It should definitely bring up the stories / content!

Yep, great points. The HTTP workflow definitely adds a lot of overhead, but I think it is still usable for a whole class of aplications. For example, anytime you can saturate the CPU, or outgoing bandwidth (use clients machine as a spider), this works really well.

As far as centralized servers & data storage.. I didn't cover this in the post, but I've been thinking a lot about using bittorrent to address this, and I think it's totally feasible. All you need is several thousand seed servers and you'll have a worldwide file system / job tracking queue. ;)

Some performance benchmarks: http://gist.github.com/64391

They're not conclusive, but give you an idea of relative performance.

Hmm, interesting idea. I would have to post-process the generated images to add the text.. easily down with a GUI tool, would require some mucking around on the command line.

Yep, if you want to see it in full 1280x720 glory, you can grab the AVI files directly:

Rails ~180mb: http://vimeo.com/download/video:87550087?e=1233100930&h=...

Dr Nic ~30mb: http://vimeo.com/download/video:87550019?e=1233100802&h=...

mtw, haven't deployed it in production, but playing with it. The nice thing about DBSlayer is it provides the round-robin balancing as well! (Read from multiple slaves, transparently)

I don't think that's the case at all. The problem is exactly the same in any language - which is why we've seen a multitude of Java / Perl / Python / Ruby / C drivers developed to do the exact same thing.

As someone has already pointed out, it's not about the threading, it's about turning a blocking request, into an asynchronous one. (Deferring work until you have the data to perform meaningful actions with it).

ajross: Ruby / Python doesn't have a great threading model (GIL in both cases is the culprit). Hence, if you have an app-server which is single threaded (event loop), or have other locks around servicing requests (like Rails Dispatcher), when the server makes the DB call, it effectively becomes unresponsive until the data is fetched.

You're absolutely right, sockets are cheap (if you can defer to kernel's select()) which is exactly what we're doing here. Instead of doing blocking IO, we convert the DB call into an asynchronous call.

Would love to get some feedback from the Y-crowd on this. Once the dust settles, I'll report the results.

Either that, or just tackle me at the upcoming Startup School event!

Not quite, it's more of a customized statistical function at this point -- Postrank. We're working on a whitepaper which will delve into the internals..

We launched a new firefox extension which intergrates PostRank into GoogleReader. Would love to hear some feedback. First come, first serve invites: http://gr.aiderss.com/?ycomb

Fair enough, but this is / was a controlled experiment. The codebase did not change, the method through which the cached content was served did. Hence the textured cube argument is not the best analogy here, I think. :)

Having said that, I agree -- there is a lot of other variables out there, and they should not be swept under the rug.

Yup, definitely true. Having said that, we tend to overuse this thinking even when we don't really have to. This is arguably a scheme that's better adapted to new codebases. :)

Are you certain? This must be new, because before your would get a fresh machine every time. Anytime you boot, AMZ looks at the image you want to run, and they unpack and uninstall it for you, meaning that even a reboot led to a clean drive. Now, there's been some talk about 'shadow copies' where you might even get access to other customers data by simply starting a deep scan on the drive.. but that's hardly persistence.

"we" - if you want to be a big dog, you gotta act like one.

1) The data is not persistent -- meaning, if your server dies, you loose your database with it. Rebooting the server gives you a clean slate.

This theoretically can be addressed with a complex backup/redundancy model, but frankly, it's not worth the trouble. Alternatively, you can use a distributed filesystem based on S3, but the performance will be poor. Long story short, your database is your bread and butter, and EC2 simply can't provide the basic services required to run a DB efficiently.

2) Dynamic DNS. Extra headaches, simply not worth it.

EC2 was not designed for persistent data storage, it's a compute cloud.