Why was it not possible to change the scale by adding servers to sites like facebook?

Question

I was looking for an explanation of why twitter had to migrate some of its mid-size product from Rails to Scala. What prevented them from scaling the way they use facebook, adding servers as their user base expands. More specifically, in terms of Ruby / Rails technology, did this prevent the twitter team from using this approach?

Answer 1

This is not that Rails does not scale, but rather requests for live data in Ruby (or any interpreted language) do not scale, since they are comparatively much more expensive in terms of processor and memory usage than their compiled languages.

Now, if Twitter was another type of service that had the same huge user base but served data that changed less frequently, Rails could be a viable option through caching; that is, completely eliminate direct requests to the Rails stack and unload them on an external server and / or in-memory cache. Great article on this topic:

How Basecamp Next got so damn fast

However, Twitter did not remove Rails to scale problems alone, they made a switch because Scala, as a language, provides certain built-in guarantees about the state of your application, which interpreted languages ​​cannot provide: if it compiles, time wasted such as typos with fat fingers, incorrect method calls, incorrect type declarations, etc. simply cannot exist.

For Twitter, TDD was not enough. A quote from Dijkstra in Programming in Scala illustrates this point: "testing can only prove the existence of errors, not their absence." As their application grew, they found it increasingly difficult to track bugs. The mysterious magical tour was an obstacle that went beyond performance, so they made a switch. By all accounts, a successful success, Twitter is Scala, which is Facebook for PHP (although Facebook uses its own ultra-fast C ++ preprocessor, so little cheating ;-))

To summarize, Twitter has made a switch for both performance and reliability. Of course, Rails is generally at an innovative level, so 99% of non-Twitter apps around the world can handle the interpreted language perfectly (although, now I'm firmly on the compiled language side of the fence, Scala is too good!)

Answer 2

No platform can scale indefinitely, while at the same time dealing with complex data sets that change a point in time. Language and infrastructure are important, but how you build your site, data access patterns matter.

If you've ever played games like Transport Tycoon or Settlers, where you have to spend resources around, you'll know how you need to stay on top of infrastructure upgrades as you increase usage.

Scaling platforms like Facebook and Twitter is an endless task. The number of users is constantly growing, and you are forced to add additional functions and functions. This is an ongoing process of updating one bit, which causes more effort on the other bit.

Throwing servers at a problem is not always the answer, and sometimes it can cause more problems.

Answer 3

http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster links to a set of change messages, including a decent history of steps taken over time.

The short version is that Ruby and Rails did not provide the performance and reliability needed for this service. Given the scale, this is not surprising; most COTS solutions are not satisfactory at the very large end of the scale.

High scalability covers many questions about architecture at this top end for other sites, and therefore helps to answer broader questions in this area.

Answer 4

They could throw more hardware into the problem, but it is much more expensive than just writing more efficient code. Like many high-level structures, Ruby on Rails does a great job of many things, but high performance is not one of them. Compiled languages ​​will always be faster than interpreted languages.

Answer 5

Facebook (and Google), adding more servers, but at the same time they violate their application in various services. These services communicate by a consistent interface and type, and now they are free to create these services in any technology that they consider appropriate. Just because you read that facebook uses php does not mean that all of their backend services are served by php (and this does not make sense, since you can choose any technical stack in SOA).

I think this video is the best answer to your question:

"From Ruby to JVM" https://www.youtube.com/watch?v=ohHdZXnsNi8

Answer 6

I think one important drawback here is the platform. Yes, we had a compiled and interpreted argument and a few others. But one of the important aspects was the platform. There are different Ruby VMs, but none of them liked it, although they tweaked it a bit. But scala works on the JVM and twitter engineers. Why didn’t they try / choose JRuby? Well, I think the reasons mentioned above come here in the game.

Answer 7

Linear wins with parallelism (this is what several servers have) are extremely rare and very application dependent. Yes, there is how the GPU does most of its work. If you use static pages without session state, this will also be the case.

For the most part, however, adding servers does not increase performance linearly (i.e. 10 servers are not 10 times faster than 1 server), which means that any winnings you can make on one server will have much more impact than just adding servers. It doesn't seem like Twitter has a bunch of servers, does it?