توییتر را دوست دارم، جمله‌هایی که باید در 140 حرف جایشان داد و به سرعت برای دوستانی که تو رو دنبال می‌کنند منتشر می‌شود و پاسخ‌هایی که به همان شیوه‌ی خلاصه‌گویی به تو می‌دهند. زیبایی توییتر در سادگی و کاربردی بودنش است و در قدرت «لحظه‌نگاریش» که در همان لحظه هم پاسخ می‌گیری. یک گفتگوی چند جانبه‌ی لحظه‌ای که پیوسته ادامه دارد: در هر لحظه در سراسر جهان؛ هزاران نفر توییت می‌کنند. اما شواهد نشان می‌دهد که این گفتگوی زیبا محکوم به خاموشی است. توییتر اهداف جاه‌طلبانه‌ای دارد ولی به خاطر دست‌کم گرفتن پیچیدگی کار محکوم به خاموشی است؛ دست‌کم اگر در رویه‌‌ی فعلی‌اش تغییر اساسی ایجاد نکند.
دشواری توییتر چیست؟
سرورهای توییتر پاسخ‌گوی تعداد روزافزون کاربران «توییت‌کن» نیستند. روزی (و اخیرا ساعتی) نمی‌گذرد که دچار اختلال نشوند و زیر بار انبوه پیام‌ها کمر خم نکنند. مشکل اصلی توییتر را اگر بخواهم در یک جمله خلاصه کنم می‌شود:
پیام‌رسانی گروهی (Group Messaging) در مقیاس بزرگ کار بسیار پیچیده‌ای است.
توییتر یک سیستم پیام‌رسان بزرگ است (اینجا را ببینید). هر پیامی که می‌نویسید به تعداد مشخصی کاربر به طور همزمان ارسال می‌شود. پاسخ‌های هر کدام از آن‌ها هم به همه‌ی کسانی که آن‌ها را فالو می‌کنند ارسال می‌شود. ارسال (و دریافت) تعداد زیادی پیام برای تعداد زیادی کاربر کار ساده‌ای نیست. در واقع اصلا گول ظاهر ساده‌ی توییتر را نخورید: کاری که توییتر انجام می‌دهد بسیار پیچیده و سنگین است.
عده‌ای اعتقاد دارند، به ازای هر کاربری که در توییتر اضافه می‌شود، حجم عملیات محاسباتی لازم به صورت نمایی (Exponential) افزایش می‌یابد. وضعیتی که رویارویی با آن دست‌کم با معماری فعلی توییتر به مرزهای «غیر ممکن» نزدیک شده است.
شبکه‌های اجتماعی هم مشکل مشابهی دارند؛ ولی معمولا با پیچیدگی کمتر، چرا که بیشتر پیام‌های کاربران به یک کاربر خاص ارسال می‌شود، برخلاف توییتر که در آن همه‌ی پیام‌ها برای همه‌ی مخاطبان یک کاربر یا یک گروه از پیش تعریف شده ارسال می‌شود. با این‌حال شبکه‌های اجتماعی هم سال‌ها دست به گریبان حل مشکل پیام‌رسانی گروهی بودند. راه‌حل برخورد با مساله‌ای چنین پیچیده، باید نوآورانه و متناسب با مقیاس کار باشد. کاری که مثلا گوگل در برخوردش با حجم عظیم اطلاعات و پردازش لحظه‌ای انجام داد.
هیچ ارزانی‌ای بی‌حکمت نیست
توییتر از چارچوب «روبی روی ریل» (RubyOnRails) استفاده می‌کند که اگر چه برای محصولات شبکه‌ای با تعداد کاربران محدود یا پیچیدگی کمتر مناسب است، احتمالا برای نرم‌افزار سنگین و پرمحاسبه‌ای مانند توییتر انتخاب بهینه‌ای نبوده است. «روبی روی ریل» به طراحان توییتر اجازه داد که محصول خود را خیلی زود و ارزان به بازار عرضه کنند، اما برای کاری در این مقیاس نمی‌تواند با معماری‌های مبتنی بر جاوا یا C رقابت کند. سرنوشت توییتر به ما یادآوری می‌کند که «هیچ ارزانی‌ای بی‌حکمت نیست».
چند روزی است که برای حل موقتی مشکل، تیم فنی توییتر سرویس پاسخ (Reply) را خاموش می‌کنند. این یک اشتباه بزرگ است و نه تنها راه حل نیست، بلکه کاربران را از توییتر به رقیب قدرتمند و تازه‌نفس‌اش فرندفید می‌راند. حل مشکل توییتر راه‌کار اساسی می‌طلبد.
توییتر محبوب‌ترین سرویس میکروبلاگینگ یا لحظه‌نگاری است. اما برای این‌که زنده بماند باید معماری خود را به طور زیربنایی عوض کند و برای این‌کار به مدیریت جذب سرمایه نیاز دارد. در بازار پر رقابت امروز، اگر توییتر نجنبد، چندی نخواهد گذشت که برای همیشه خاموش خواهد شد.
پی‌نوشت:
درباره‌ی بحث این‌که مشکل توییتر به چارچوب روبی‌روی‌ریل برمی‌گردد یا خیر این مطالب را ببینید: {4}، {5}، {6}
مشترک خوراک بامدادی شوید
کامل
فقط مطالب
فقط لینکدونی
بامدادی 
لینکدونیتو عشقه!
لایکلایک
اوهوم! باید عوضش کنه! یادش بخیر اون قدیما چه خاطراتی داشتیم با توییتر !
لایکلایک
عکس جوجه هه الان لود شد =)))
با تیر سرخپوستی زدن کشتنش ! خونش رو نریختی زمین اما !
لایکلایک
اين يكي را لينكيديم!
لایکلایک
من فرندفید را ترجیح میدهم، چون همان کارهای توئیتر رو میشه توش با امکاناتی خیلی وسیعتر انجام داد.
لایکلایک
نوشته‌ات ژورنالیستی و حرفه‌‌ای بود.
در بخش Rubyخیلی راحت نمی‌توان نظر داد. مثلا یاهو یک زمانی از یک زیان خاص خود به php هجرت کرد. ارزان بودن (مثل Php) دلیلی بر کم کیفیت بودن نیست. در ضمن کاری توییتر می‌کند ممکن است که حجم زیاد داشته باشد ولی احتمالا پیچیده نیست. همچنین مسئله دیتابیس احتمالا از مسئله زبان مهمتر است. در آخر یک سیستم اگر خوب طراحی شده باشد می‌تواند (البته به سختی) بعضی از قسمتهای Critical Missionخود را به زبانهای دیگر (از جمله Java و ++C) هجرت دهد.
راستی وبلاگ http://logosoftime.org/char را شاید زنده کنم (انگلیسی) و http://logosoftime.org/parsichar (فارسی) به فیدهایت اضافه کن شاید بتوانیم کمی در مورد مسائل مختلف آنجا با هم صحبت کنیم
لایکلایک
روبی یک چهارچوب (Framework) نیست بلکه یک زبان برنامه نویسی است. RubyonRails یا به اختصار Rails یک چهارچوب مبتنی بر روبی است که برای ساخت نرم افزارهای تحت وب استفاده می‌شود.
«گر چه برای محصولات شبکه‌ای با تعداد کاربران محدود مناسب است، برای نرم‌افزار سنگین و پرمحاسبه‌ای مانند توییتر انتخاب بهینه‌ای نبوده است»
این جمله شما از دیدگاه فنی درست نیست. وب سایت های بسیار بزرگ تری از توییتر از ریلز استفاده می‌کنند و مشکلی ندارند (http://rails100.pbwiki.com/Alexa+Rankings).
ریلز تنها لایه وب سایت توییتر را کنترل می‌کند حال آنکه بنا به گزارش های غیر رسمی بیش از ۶۰ درصد ترافیک سرورهای توییتر از طریق API و به خاطر سایر ابزارهایی است که از آن استفاده می‌کنند و API یعنی لایه زیرین توییتر با جاوا و C نوشته شده و ربطی به روبی یا ریلز ندارد.
لایکلایک
@صادق:
ولی توییتر مهربون و صمیمیه فضاش. فرندفید یه فضای دیگه داره…
@شهریار:
تا تعریف ما از مشکل یا پیچیده چه باشد. سر و کله زدن با حجم زیاد با امکانات دنیوی، خودش یک جور پیچیدگی است. کار توییتر از این نظر پیچیده است و نمونه‌اش را هم کم داریم. چنین حجم پیام‌رسانی گروهی را تا به حال جایی نداشته‌ایم.
نکته دقیقا همین است. جایی می‌خواندم که تیم طراح توییتر بخش کوچکی بوده‌اند و احتمالا روی معماری آن به اندازه‌ی کافی سرمایه‌گذاری نشده. یعنی طراحی انجام شده برای این مساله‌ای با این خصوصیات ناکارآمد بوده یا در واقع مساله را کوچک‌تر از آنچه که هست دیده‌اند.
بحث این‌که اگر طراحی خوب و عالی انجام می‌شد، آیا باز هم روبی روی ریل پاسخ‌گو می‌بود، را من نمی‌توانم جواب بدهم. ولی چند جا دیدم که مدعی شده بودند روبی روی ریل محدودیت‌های سرعت و پردازش در کاربردهای بزرگ دارد.
لایکلایک
@Aziz:
ممنون، اون نکته رو اصلاح کردم. روبی روی ریل چارچوبی است که توییتر استفاده کرده.
اما در مورد این‌که مشکل توییتر به خاطر استفاده از این چارچوب باشه: در درجه‌ی اول توییتر شاید بزرگترین سایتی باشه که روی روبی روی ریل کار می‌کنه. در مورد ریشه‌ی مشکل هم راستش این نظر من نیست، چند تا جا دیدم، از جمله خود تیم فنی توییتر که مشکل کند بودن توییتر رو به کندی ذاتی روبی روی ریل نسبت داده بودن که به خاطر سطح‌بالا (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/)
البته هستند کارشناسانی که این موضوع رو بهانه‌گیری می‌دونن و طراحی نامناسب با مقیاس کار رو تنها دلیل مشکلات توییتر می‌دونن.
یه نکته‌ی دیگه. نوع کارکرد وب‌سایت‌های بزرگ دیگه شاید طوری باشه که با روبی روی ریل جواب بده. نوع کاری که توییتر می‌کنه بنا به دلایلی که توی نوشته آوردم به نوعی منحصر به فرده و نمونه‌اش رو توی سایت‌های بزرگ معمولی نمی‌بینیم.
باز هم ممنون از کامنت و توجهت.
لایکلایک
@aziz:
این رو هم بخون خیلی جالبه. خود وبلاگ توییتر می‌گه:
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/
لایکلایک