Twitter is, fundamentally, a messaging system. Twitter was not architected as a messaging system, however. For expediency’s sake, Twitter was built with technologies and practices that are more appropriate to a content management system.

و توضیح این‌که مشکل از کجاست رو هم دقیقا این‌جا نوشته:
http://www.sitepoint.com/blogs/2008/06/06/did-rails-sink-twitter/

اما در مورد این‌که مشکل توییتر به خاطر استفاده از این چارچوب باشه: در درجه‌ی اول توییتر شاید بزرگترین سایتی باشه که روی روبی روی ریل کار می‌کنه. در مورد ریشه‌ی مشکل هم راستش این نظر من نیست، چند تا جا دیدم، از جمله خود تیم فنی توییتر که مشکل کند بودن توییتر رو به کندی ذاتی روبی روی ریل نسبت داده بودن که به خاطر سطح‌بالا (high level) بودنش کنده. مثلا آلکس از برنامه‌نویسان توییتر می‌گه:

By various metrics Twitter is the biggest Rails site on the net right now. Running on Rails has forced us to deal with scaling issues – issues that any growing site eventually contends with – far sooner than I think we would on another framework.The common wisdom in the Rails community at this time is that scaling Rails is a matter of cost: just throw more CPUs at it. The problem is that more instances of Rails (running as part of a Mongrel cluster, in our case) means more requests to your database. At this point in time there’s no facility in Rails to talk to more than one database at a time. The solutions to this are caching the hell out of everything and setting up multiple read-only slave databases, neither of which are quick fixes to implement. So it’s not just cost, it’s time, and time is that much more precious when people can['t] reach your site.None of these scaling approaches are as fun and easy as developing for Rails. All the convenience methods and syntactical sugar that makes Rails such a please for coders ends up being absolutely punishing, performance-wise. Once you hit a certain threshold of traffic, either you need to strip out all the costly neat stuff that Rails does for you (RJS, ActiveRecord, ActiveSupport, etc.) or move the slow parts of your application out of Rails, or both.It’s also worth mentioning that there shouldn’t be doubt in anybody’s mind at this point that Ruby itself is slow. It’s great that people are hard at work on faster implementations of the language, but right now, it’s tough. If you’re looking to deploy a big web application and you’re language-agnostic, realize that the same operation in Ruby will take less time in Python. All of us working on Twitter are big Ruby fans, but I think it’s worth being frank that this isn’t one of those relativistic language issues. Ruby is slow.

(http://www.radicalbehavior.com/5-question-interview-with-twitter-developer-alex-payne/)

البته هستند کارشناسانی که این موضوع رو بهانه‌گیری می‌دونن و طراحی نامناسب با مقیاس کار رو تنها دلیل مشکلات توییتر می‌دونن.

یه نکته‌ی دیگه. نوع کارکرد وب‌سایت‌های بزرگ دیگه شاید طوری باشه که با روبی روی ریل جواب بده. نوع کاری که توییتر می‌کنه بنا به دلایلی که توی نوشته آوردم به نوعی منحصر به فرده و نمونه‌اش رو توی سایت‌های بزرگ معمولی نمی‌بینیم.

باز هم ممنون از کامنت و توجهت.

@شهریار:
تا تعریف ما از مشکل یا پیچیده چه باشد. سر و کله زدن با حجم زیاد با امکانات دنیوی، خودش یک جور پیچیدگی است. کار توییتر از این نظر پیچیده است و نمونه‌اش را هم کم داریم. چنین حجم پیام‌رسانی گروهی را تا به حال جایی نداشته‌ایم.

نکته دقیقا همین است. جایی می‌خواندم که تیم طراح توییتر بخش کوچکی بوده‌اند و احتمالا روی معماری آن به اندازه‌ی کافی سرمایه‌گذاری نشده. یعنی طراحی انجام شده برای این مساله‌ای با این خصوصیات ناکارآمد بوده یا در واقع مساله را کوچک‌تر از آنچه که هست دیده‌اند.

بحث این‌که اگر طراحی خوب و عالی انجام می‌شد، آیا باز هم روبی روی ریل پاسخ‌گو می‌بود، را من نمی‌توانم جواب بدهم. ولی چند جا دیدم که مدعی شده بودند روبی روی ریل محدودیت‌های سرعت و پردازش در کاربردهای بزرگ دارد.

راستی وبلاگ http://logosoftime.org/char را شاید زنده کنم (انگلیسی) و http://logosoftime.org/parsichar (فارسی) به فیدهایت اضافه کن شاید بتوانیم کمی در مورد مسائل مختلف آنجا با هم صحبت کنیم