Let’s be totally clear, I’m not talking about Disk IO specifically either: Instead, what I’m saying is that Twitter is an IO Bound application, be it disk OR network.

I think that it is naive of you to even think that some simple (cacheable) joins are what is bringing down the Twitter service.

Instead, you should think about all of the IO that is going on between the IM network, the SMS network and the outbound stream networks to friendfeed, summerize, etc.

Thus, the bottlenecks become:

* Database [Disk IO] (from pulling-out messages for Web Users/API)
* IM/Event-Bus [Network IO] (for pushing messages to realtime targets)

So, what this means is that your job will be to partition message reads and writes to both storage and realtime targets.

And with that, again, Good Luck.

Network load = How much data needs to be sent to individual users each time things change. Quite minimal, when it come to Twitter, once you figure out who to send data to. I’m not talking about disk I/O at 7:22.

Computational load is high, because every time the site goes through the database, it has to figure out who those changes go to. Caching and moving the problem into RAM would make this less of a problem, but I haven’t seen enough of the architecture to figure out if that’s the right course of action yet.

You’re looking at this system from the “Oh look, we need to send lots of data each time” perspective, so you assume it’s an I/O bound problem. Well, no. It’s computationally (and disk I/O) bound because the site needs to go through all of the user joins, each time something happens.

Additionally, I’m not sure why you mention streaming; In my experience, streaming is network and disk I/O bound, and also heavily CPU bound if you are selling streams for pay-per-minute (with significant db activity and many authorizations per-minute if you’re sending lots of telemetry back and forth.)

Why do I say that this is *like* IRC? It’s not IRC because it’s not “real time”, but, it’s a set of users, with a set of statuses, over a wide area, and hopefully, over a set of distributed servers.

We should be able to get Twitter into that state; Ultimately, I’ll be able to speak to this once I’ve had more time with the code, but right now I feel that this is a possibility.

At around 7:22 he says that the problem with Twitter is that the “Computational Load” (CPU) is higher than “Network Load” (IO)? How is this the case?

Anyone worth their salt understands that Twitter must be an IO problem because they are having problems storing and retrieving all of these messages into their database in realtime. Even the IM & SMS aspects of Twitter are IO Bound.

Streaming is so much more of an IO bound problem than a CPU bound problem.

Give me a break, John Adams. Twitter is NOT IRC.

On the flip side, good to see Twitter spending more of its ridiculous venture money!

By the looks of things they may have previously relied on Sam Adams to slove their problems…

Joe

Good luck w/ the new gig, man.

Good to see that you are going to be fixing twitter – remember me????? old old boston days? we almost went in to business on an ISP together back in 1992? wow i am getting old.

Ping me if you like – best wishes

Mark

Seriously, all these twats who use twitter are one big daisy chain. This web service is of no consequence to anybody outside some piddly tech centers.

It is federated and scales pretty well and I interpreted John as pointing out that it was *that* problem that has been solved, and not necessarily that Twitter fulfills the same function as IRC.

When Mr. Winer writes something, you simply agree with him: tell him he made a good point and build him up. Be careful to not expand on his ideas. He invented RSS and its brilliant polling model DON’T YOU KNOW. He doesn’t need any ideas YOU come up with, nor any ideas he failed to consider.

What’s this? You say you weren’t disagreeing with him?

Well, just to be clear on that point, you should openly embrace his words, and follow the correct Winer Interaction Protocol (WIP).

These posters have it nailed:

# 10 “Great point Winer, I always have thought about it as IRC too.”
# 11 “Yeah, IRC without the … mentality”

#29 ( “Yes Winer, twitter isn’t IRC” ) is a rather dangerous, and should be used only by WIP experts who can mask their distain with obsequiousness.

“Go OBAMA!”

>Twitter is not IRC. It’s asymmetric. If you can hear me, that doesn’t mean I can
>hear you. And not everyone who hears you can hear me. That’s the biggie. >Programmers always think it’s IRC.

Sure, it’s asymmetric, in that people don’t know if the respondent can respond immediately to prior messages — that’s because of the lack of real-time status data, but the service should respond at real-time rates.

Why should status be slower than anything else?

Good luck on the new gig John.