Live data from Hacker News

The Architecture Twitter Uses to Deal with 150M Active Users

highscalability.com

161–166 of 166 posts

Re: The Architecture Twitter Uses to Deal with 150M Active Users

#161
i wrote a synchronous twitter push model. single machine, 4GB RAM x86_64

GIST: push 48 M messages in less than 5 seconds.

some data from experiment:

Total Super Users : 100 Each Super User Follower Count: 1234567

Total Connections Made 123456700 Time To Make NetWork : 32 secs

Making New 40 messages Time To Push 49,382,720 messages : 5 secs

Making New 40 messages Time To Push 49382720 messages : 5 secs

Making New 40 messages Time To Push 49382720 messages : 5 secs

Making New 40 messages Time To Push 49382720 messages : 6 secs

--------------------------

code at : https://github.com/akuchlous/Twitter-TimeLine-Push-Experimen...

--------------------------

with distributed, + twitter constraints (filter messages, links .. etc), 5 seconds seems to be decent.

Re: The Architecture Twitter Uses to Deal with 150M Active Users

#162
post #111

Earlier quoted context omitted.

A simple Google search defeats your belief http://redis.io/commands/set > Options > EX seconds -- Set the specified expire time, in seconds. http://redis.io/commands/expireat > EXPIREAT has the same effect and semantic as EXPIRE, but instead of specifying the number of seconds representing the TTL (time to live), it takes an absolute Unix timestamp (seconds since January 1, 1970)

I apologize for not being specific. Setting timed expiration is not what I meant. Memcache will fill the entire cache and auto select items to be destroyed, based on current resource availability and order of entry into the cache (FIFO). I want that behaviour. I do not want to set and manage the time things expire.

That's covered as well

http://oldblog.antirez.com/post/redis-as-LRU-cache.html

Re: The Architecture Twitter Uses to Deal with 150M Active Users

#163

Earlier quoted context omitted.

> I have not used nginx, and have never heard of it spoken about in such glowing terms. Seriously? There are lots of glowing blog posts, articles etc about Nginx all the time, including on HN. Just last week or so, it was reported that it powers the majority of the top-1000 biggest sites.

Yeah I guess what I mean was the post I was replying to called it the most useful tool powering the internet. I have not seen that before. I also like to ask people on HN who seem extremely passionate about something to explain why they are passionate because you often learn something new, that you often would not from articles etc.

nginx is fast and lightweight. Apache is a bloated mess in comparison. That's about it.

Re: The Architecture Twitter Uses to Deal with 150M Active Users

#164

Earlier quoted context omitted.

Yeah I guess what I mean was the post I was replying to called it the most useful tool powering the internet. I have not seen that before. I also like to ask people on HN who seem extremely passionate about something to explain why they are passionate because you often learn something new, that you often would not from articles etc.

nginx is fast and lightweight. Apache is a bloated mess in comparison. That's about it.

Late reply, but just saw this. So would you go as far as saying it never makes sense to use apache anymore? Is there any negative tradeoff to nginx?

Re: The Architecture Twitter Uses to Deal with 150M Active Users

#165

I really question the current trend of creating big, complex, fragile architectures to "be able to scale". These numbers are a great example of why, the entire thing could run on a single server, in a very straight forward setup. When you are creating a cluster for scalability, and it has less CPU, RAM and IO than a single server, what are you gaining? They are only doing 6k writes a second for crying out loud.

Something is not easy to say simple or complex by just looking at the shape or counting the number of them.

One big powerful server's architect and circuit design is not that simple as what it looks like, in the other hand, 2000 standard servers are not that complex as what they are.

The way of how you think is the key. You can think that the 2000 servers is a big computer cluster, but I prefer to think each one of them is a simple replaceable black box.

I can show you some scenarios at the following to explain why 2000 servers make more sense than one big machine,

Firstly, When I want to upgrade the system to deal with a suddently increased load I don't need to call vendor to arrange an onsite upgrade service, I can do it by connecting more servers right away, and when the load decreased, then I can disconnect some servers. This makes the maintenance job is more flexible and more convenient.

The second one is when I estimate the performance of the whole system, I can focus on estimating the performance for one server first, and then add them on, even there are some variables need to be involved into the calculation, it is still more clear and simpler than estimating the performance by looking at the vendor provided system specification.

The last scenario is that you cannot separate one big machine into different geolocations to handle the access all over the world, but seperate 2000 servers is much easier and doable. Moreover, different geolocation deployment can provide a genric 24*7 online service as some nature disasters happens.

When we engineer things, we should split one big(complex) thing into multiple small parts and keep it with a simplest structure or function, and later, we connect these small parts together.

English is not my first language, so if somewhere sounds wired, please excuse me.

Re: The Architecture Twitter Uses to Deal with 150M Active Users

#166

Earlier quoted context omitted.

I do consider it a pathology when tiny services, or tiny apps in a corporate structure, act like they have the problems of Google. You are not Google. You do not have Google's problems. You do not have scaling issues. For you, N is small and will stay small . Stop giving me this delusional resume-padding garbage to implement. For you, here, it is delusion and lies.

The point here is that Twitter really is one of the cases where vertical scaling is not, on the balance of non-functional requirements to engineering overhead, the right decision. They really do need to pay the complexity piper.

Oh, yeah. I'm speaking to everyone else :-)
Post reply on HN