Insight IT

Архитектура Stack Exchange Network

Иван Блинков — Thu, 31 Mar 2011 16:05:00 +0400

Stack Exchange Network представляет собой сеть из 46 сайтов вопросов-ответов на совершенно разные темы от программирования до кулинарии. Проект вырос из известной в узких кругах тусовки программистов Stack Overflow, об архитектуре которой я уже рассказывал чуть больше года назад. Проект активно развивается и уже появилось приличное количество новой информации, которой я и спешу с Вами поделиться.

Статистика

95 миллионов просмотров страниц в месяц
800 HTTP запросов в секунду
180 DNS запросов в секунду
Загруженность интернет-канала в 55 Мбит/с
16 миллионов уникальных пользователей в месяц

Технологии

Разработка

C# - основной язык программирования
Visual Studio 2010 Team Suite - IDE
Microsoft ASP.NET 4.0 - framework
ASP.NET MVC 3 - web Framework
Razor - генератор шаблонов
jQuery 1.4.2 - JavaScript framework
LINQ to SQL и немного чистого SQL - доступ к данным
Mercurial и Kiln - контроль версий исходного кода
Beyond Compare 3 - инструмент для сравнения

Программное обеспечение

WISC стек получен условно-бесплатно с помощью BizSpark
Windows Server 2008 R2 x64 - основная операционная система
MS SQL Server 2008 R2 на Windows Server 2008 Enterprise Edition x64 - база данных
Ubuntu Server
CentOS
IIS 7.0 - веб-сервер
HAProxy - балансировка нагрузки
Redis - используется как распределенная система кэширования
CruiseControl.NET - сборки и автоматическая система развертывания кода
Lucene.NET - полнотекстовый поиск
Bacula - резервное копирование
Nagios (с плагинами n2rrd и drraw) для мониторинга
Splunk - сбор и агрегация логов
SQL Monitor от Red Gate - мониторинг SQL Server
Bind - DNS
DotNetOpenId - реализация OpenID на .NET
WMD - текстовый редактор
Prettify - подсветка синтаксиса
MarkdownSharp - обработчик разметки Markdown на C#
Flot - построение графиков на JavaScript

Внешние сервисы

reCAPTCHA - защита от спама
Google Analytics - веб-аналитика
Kiln - Mercurial хостинг
Pingdom - внешний мониторинг и уведомления
CDN не используется, его роль выполняет sstatic.net, отдельный домен для статичных файлов SEN без cookie

Оборудование

Датацентры

1 стойка в Peak Internet, штат Орегон (чат и обнаружение данных)
2 стойки в Peer 1, Нью-Йорк (остальная часть SEN)

Серверы

10 веб-серверов:
- Dell R610
- 1x Intel Xeon Processor E5640 @ 2.66 GHz
- 16 GB RAM
- Windows Server 2008 R2
- IIS
2 сервера баз данных:
- Dell R710
- 2x Intel Xeon Processor X5680 @ 3.33 GHz
- 64 GB RAM
- 8 жестких дисков
- MS SQL Server 2008 R2
2 виртуальных сервера для балансировки нагрузки:
- 1x Intel Xeon Processor E5640 @ 2.66 GHz
- 4 GB RAM
- Ubuntu Server
- HAProxy
2 сервера для кэша:
- Dell R610
- 2x Intel Xeon Processor E5640 @ 2.66 GHz
- 16 GB RAM
- CentOS
- Redis
1 сервер для резервного копирования:
- Dell R610
- 1x Intel Xeon Processor E5640 @ 2.66 GHz
- 32 GB RAM
- Linux
- Bacula
1 сервер для мониторинга, управления и сбора логов:
- Dell R610
- 1x Intel Xeon Processor E5640 @ 2.66 GHz
- 32 GB RAM
- Linux
- Nagios
2 сервера для виртуализации:
- Dell R610
- 1x Intel Xeon Processor E5640 @ 2.66 GHz
- 16 GB RAM
- VMWare ESXi

Сетевое оборудование

2 маршрутизатора на Linux
5 свитчей Dell PowerConnect

Прочее

Rovio - маленький робот, позволяющий удаленным разработчиком посетить офис "виртуально"

Команда

14 разработчиков
2 системных администратора

Что нового?

HAProxy стал использоваться вместо Windows NLB так как HAProxy является быстрым, нересурсоемким, бесплатным решением, которое работает. Полностью прозрачен для серверов, легче обслуживать по сравнению со старым решением, располагается на виртуальных машинах.
CDN не используется, так как даже "недорогие" решения обходятся в очень приличную сумму по сравнению с тем трафиком, который входит в тарифный план хостинг-провайдера. Самое дешевой решение CDN от Amazon обошлось бы как минимум на тысячу долларов в месяц дороже при текущем уровне использования трафика.
Резервное копирование на диски для быстрого восстановления и на кассеты для "истории".
Полнотекстный поиск в SQL Server плохо интегрируется, нестабилен и обладает низким качеством результатов, так что они перешли на Lucene.
Все сайты в SEN теперь работают на общей платформе: используется общее оборудование и программное обеспечение.
Проект разделен на разные сайты для разных ниш, чтобы полностью изолировать группы аудитории, специализирующиеся в каждой конкретной области.
Используется агрессивное кэширование, большинство страниц кэшируются в виде HTML для анонимных пользователей средствами IIS.
Используется три уровня кэширования: локальный, относящийся к каждому сайту и глобальный.
Локальный кэш доступен только для каждой пары сайт/сервер:
- Используется для уменьшения сетевых задержек, по сути просто через HttpRuntime.Cache.
- Содержит такие вещи как пользовательские сессии, будущие обновления счетчиков просмотров страниц.
- Располагается полностью в оперативной памяти веб-сервера.
Кэш сайта доступен для каждого сервера, обрабатывающий запрос к конкретному сайту:
- Большинство кэшируемых данных располагаются здесь.
- Располагается в Redis.
- Redis настолько быстр, что большую часть времени доступа к кэшу занимает передача данных по сети.
- Данные сжимаются перед отправкой в Redis, так как большинство данных являются строками и у них есть масса свободных вычислительных ресурсов.
- Использование процессорных ресурсов на серверах с Redis стремится к нулю.
Глобальный кэш является общим для всех серверов и сайтов:
- Личные сообщения, квоты по API и несколько других по-настоящему глобальных вещей располагаются здесь.
- Также используется Redis.
Большинство данных в кэше удаляются через заданный период времени (обычно в районе нескольких минут) и практически никогда явно не удаляются.
Когда требуется инвалидация кэша на уровне готовых страниц, используется система подписки внутри Redis для отправки сообщений в соответствующую часть системы кэширования.
Для системы ввода-вывода они выбрали Intel X25 SSD в RAID10. RAID решил многие вопросы с надежностью, а SSD показывают отличную производительностью по сравнению с FusionIO при существенно более низкой цене.
Стоимость лицензий используемых продуктов Microsoft составила бы 242 тысячи долларов. Но так как они используют программу BizSpark, им не пришлось платить большую часть этой суммы.
Сетевые карты от Broadcom заменяются на сетевые карты от Intel на основных production серверах. Это решило большинство проблем с потерями соединений, пакетов и таблицами ARP.

Источники информации

Спасибо за внимание! Для оперативного получения свежей информации о высоконагруженных интернет-проектах рекомендую подписаться на RSS.

Как проект Ravelry дорос до 10 миллионов запросов с помощью Rails

Иван Блинков — Thu, 24 Sep 2009 11:31:00 +0400

Данная статься основана на замечательном интервью, взятом Tim Bray у Casey Forbes, создателя Ravelry, сайта на Ruby on Rails, поддерживаемое сообществом вязальщиц и специалистов по вышивке крючком численностью более 400000 человек.

Casey и его небольшой команде удалось реализовать массу великолепных идей на Ravelry. Этот сайт очень сфокусирован на своей тематике и представляет собой большую информационную ценность для заинтересованных лиц. Все пользователи Ravelry просто обожают этот сайт, этот факт очевиден по их комментариям полным энтузиазма и невероятно быстрому освоению Ravelry.

Десять лет назад сайт масштаба Ravelry потребовал бы далеко не один миллион долларов для поддержания своего функционирования. Сегодня же Casey является единственным разработчиком Ravelry, а поддержанием работоспособности системы занимается всего несколько человек. Изначальный процесс разработки занял у Casey 4 месяца работы по ночам и выходным. Если Вы взглянете на список технологий, используемых в Ravelry, Вам станет видно, что проект построен практически полностью на свободном и бесплатном программном обеспечении, которые просто было собрано вместе в единую полноценную систему. В сегодняшней экосистеме существует множество возможностей для того чтобы делать новые вещи просто комбинируя существующие качественные приложения, языки программирования, системы хранения, а также услуги по размещению и предоставлению доступа к веб-приложениям и данным.

Сейчас Casey и еще несколько сотрудников живут за счет Ravelry. Не это ли является мечтой любого предприятия малого бизнеса? Хотите узнать как и Вы могли бы достичь подобных успехов? Данный текст является переводом статьи How Ravelry Scales to 10 Million Requests Using Rails, автор оригинала - Todd Hoff.

Статистика

10 миллионов запросов ежедневно обрабатывается Rails (AJAX + RSS + API)
3.6 миллиона просмотров страниц ежедневно
430,000 зарегистрированных пользователей. 70,000 активно пользуются сайтом ежедневно. 900 новых пользователей регистрируется ежедневно.
2.3 миллиона проектов по вязанию, 50000 новых сообщений на форуме ежедневно, всего 19 миллионов сообщений на форуме, 13 миллионов сообщений, 8 миллионов фотографий (большая часть размещена на Flickr).
Проект начинался на небольшом VPS, но потребности в ресурсах очень быстро вышли за его возможности.
Монетизация: рекламодатели + магазин соответствующей продукции + продажа узоров

Platform

Ruby on Rails (1.8.6, Ruby GC патчи)
Percona сборка MySQL
Gentoo Linux
Servers: Silicon Mechanics (не арендуемые, в их собственности)
Хостинг: Colocation от Hosted Solutions
Интернет-канал: Cogent (очень дешево)
Capistrano для развертывания
Nginx существенно более быстрый и менее требовательный к оперативной памяти по сравнению с Apache
Xen для виртуализации
HAproxy для балансировки нагрузки
Munin для мониторинга
Tokyo Cabinet / Tokyo Tyrant для кеширования больших объектов
Nagios для предупреждений
HopToad для уведомлений об исключительных ситуациях.
NewRelic для тонкой настройки
Syslog-ng для агрегации логов
S3 для хранения данных
Cloudfront в роли CDN
Sphinx для текстового поиска
Memcached для кеширования маленьких объектов

Архитектура

7 серверов (Gentoo Linux). Средствами виртуализации (Xen) создано 13 виртуальных серверов:
- Для обработки пользовательских запросов используются Nginx и Haproxy. Запросы проходят следущую цепочку: nginx -> haproxy -> apache + mod_passenger.
- Один небольшой сервер для резервного копирования данных.
- Один небольшой вспомогательный сервер для некритичных процессов и тестирования новых версий.
- 2 сервера с 32 GB оперативной памяти для master+slave баз данных, а также поисковой системы Sphinx.
- 3 сервера приложений, состоящих из 6 Apache Passenger и запущенных экземпляров Ruby, каждый ограничен 20-ю потоками. Суммарно 6 четырехядерных процессоров и 40 GB оперативной памяти. Часть оперативной памяти большую часть времени простаивает.
5 терабайт данных располагается в Amazon S3. Cloudfront используется как CDN.
Tokyo Cabinet/Tyrant используется вместо memcached в некоторых местах для кеширования более крупных объектов, в частности уже размеченного текста в HTML.
HAproxy и Capistrano используются для вывода новых версий сайта без негативного влияния на производительность и работу пользователей.

Подводим итоги

Позвольте своим пользователям работать над Вашим сайтом за Вас. Проводите итерации и развивайтесь. Начните с чего-то, что просто работает, и позвольте людям начать пользоваться продуктом, развивать проект совместно с пользователями намного проще. Не торопясь развивайте бета-версию своего проекта. Также медленно приглашайте новых людей. Старайтесь ежедневно обсуждать с пользователями что бы они хотели увидеть нового в проекте. Разрешите им оказывать помощь в развитии проекта и результат станет существенно более обнадеживающим, утешительным, интуитивно-понятным и эффективным.
Позвольте пользователям спонсировать Ваш проект. Ravelry частично был создан за счет его пользователей, которые пожертвовали в пользу проекта более 71 тысячи долларов. Эти средства были переданы проекту просто как дар, а не в обмен на акции. Не недооценивайте значимость капитала компании. Ravelry потребовалось 6 месяцев непрерывной работы и экономии на издержках, связанных с серверным оборудованием и каналами связи, чтобы наконец-то начать получать прибыль, и полученные от пользователей средства оказались основным фактором, позволившим проекту пережить этот тяжелый период. Залогом их успеха является поддержание интереса и искры в глазах своих пользователей, подталкивание пользователей к оказанию помощи и поддержки проекту. Для этого требуется любовь к своему делу и самоотдача.
Станьте центром выбранной ниши. Найдите нишу на рынке с недостаточным предложением. Не стремитесь к массовым рынкам. Совсем не обязательно делать что-то для многих миллионов людей. Миллионы скорее всего просто зевнут от скуки и в скором времени о Вас забудут. Лучше создайте что-нибудь очень полезное для небольшой заинтересованной группы лиц и их страсть к их интересам перейдет и к Вам.
Успех не обязательно должен быть связан с масштабностью проекта, намного большее значение имеет стабильная и качественная реализация © Jeff Putz.
Основная проблема в базе данных. Практически вся работа, относящаяся к масштабируемости/настройке/производительности, так или иначе связана с базой данных. Например, изменение схемы данных для больших таблиц в MySQL всегда связано с рядом проблем, особенно если простой сервиса неприемлем. Еще один аргумент в пользу баз данных, не имеющих схем данных.
Продолжайте получать удовольствие. Casey перешел на Ruby on Rails так как ему хотелось снова заняться программированием с энтузиазмом. Этот факт стал одним из основных факторов, которые помогли сделать проект успешным.
Придумывайте новые вещи, которые будут приводить в восторг Ваших пользователей. Воспользуйтесь магией, людям это нравится. Это тоже один из принципов данного проекта. Например по этой ссылке, можно почитать об использовании очень инновационных подходов к управлению форумами.
Ruby — это круто. Он представляет собой интересный язык программирования, позволивший Ravelry быстро пройти стадию изначальной разработки и выпускать новые версии дважды в день в период бета-тестирования.
Получайте большую прибыль за счет минимизации издержек. У Ravelry есть свой магазин с соответствующей тематике продукцией, оптовые счета, принтеры и реализующая компания. Это позволяет им поддерживать издержки на низком уровне, таким образом их прибыль не уходит сторонним компаниям вроде CafePress.
Наиболее сложный переход заключается в переходе от одного сервера к нескольким. В этом процессе все меняется и становится более сложным и комплексным. Всегда имейте этот переход ввиду, когда планируете архитектуру веб-приложения.
В сегодняшней экосистеме имеется возможность делать массу различных вещей даже обладая минимумом ресурсов. Для создания комплексного сайта вроде Ravelry больше не нужно много людей или финансов. Взгляните на список различных программ, используемых в Ravelry, а также на небольшое количество людей, работающих над поддержанием работы проекта.

Некоторые люди могут жаловаться, что здесь нет практически никаких подробностей о том, как же все таки работает Ravelry. Сайты таких размеров не должны иметь развернутого описания мистического процесса его масштабирования, такие проекты могут быть построены просто из составных частей, с умом собранных вместе. И это очень здорово.

Архитектура Twitter

Иван Блинков — Sat, 10 May 2008 12:36:00 +0400

Twitter стартовал как побочный подпроект, но не смотря на это темпы его роста были впечатляющими: путь от 0 до миллионов просмотров страниц занял всего несколько коротких месяцев. Ранние решения о проектировании системы неплохо справлялись с небольшими нагрузками, но они быстро таяли под напором огромного количества пользователей, желающих разослать весточки всем своим друзьям с ответом на простой вопрос: а чем ты занимаешься?

Поначалу все винили Ruby on Rails во всех проблемах с масштабированием, но Blaine Cook, главный архитектор Twitter, встал на его защиту:

Основной для нас на самом деле является проблема горизонтального масштабирования, с этой точки зрения Ruby on Rails ничем не хуже других языков программирования или framework'ов: переход на "более быстрый" язык программирования дал бы нам 10-20% прирост производительности, в то время архитектурные преобразования, легко реализованные средствами Ruby on Rails, сделали Twitter быстрее на 10000%.

Даже если Ruby on Rails оказался невиновен, как же тогда Twitter научился с его помощью рости до все больших и больших высот?

Источники информации

Этот текст является продолжением серии переводов, автор оригинала - Todd Hoff. На этот раз написать что-либо своими силами у меня не сложилось, все мысли ушли на другой пост, который я скоро опубликую, а перевод этот получился несколько менее строгим, чем обычно, но я думаю ничего страшного.

Scaling Twitter Video от Blaine Cook.
Scaling Twitter Slides
Good News блог пост от Rick Denatale
Scaling Twitter блог пост от Patrick Joyce
Twitter API Traffic is 10x Twitter’s Site
A Small Talk on Getting Big. Scaling a Rails App & all that Jazz

Платформа

Статистика

Более 350000 пользователей. Точная цифра, как обычно, держится в секрете.
Около 600 запросов в секунду.
В среднем система поддерживает 200-300 соединений в секунду. Максимум обычно достигается при значении 800.
MySQL обрабатывает примерно 2400 запросов в секунду.
180 экземпляров приложений на Rails, использующих Mongrel как веб-сервер.
1 MySQL сервер (одна большая машина с 8 ядрами) и 1 slave, используемый лишь для статистики и отчетов.
30+ процессов для выполнения произвольных работ.
8 Sun X4100
Обработка запроса обычно занимает у Rails 200 миллисекунд.
В среднем ответ на запрос к базе данных занимает 50-100 миллисекунд.
Более 16 GB выделено под memcached.

Архитектура

Проект столкнулся с массой проблем, связанных с масштабируемостью. Маленькая птичка частенько давала сбои.
Изначально не было реализовано никаких форм мониторинга, графиков или статистики, это очень затрудняло обнаружение м решение возникающих проблем. Впоследствии были внедрены Munin и Nagios. Разработчики столкнулись с некоторыми трудностями при использовании этих продуктов в Solaris. Помимо этого был использован сервис Google Analytics, но от него обычно мало толку, особенно когда страницы даже не загружаются.
Активное использование кэширования средствами memcached:
- Например, если подсчет количества чего-либо выполняется медленно, намного эффективнее один раз запомнить результат в memcached, чем каждый раз считать его заново.
- Получение информации о статусе своих друзей - непростая задача. Вместо использования запросов информация о статусе друзей обновляется в кэше. База данных совсем не используется. Такой подход позволяет получить предсказуемое время отклика (ограниченное сверху примерно 20 миллисекундами).
- Объекты ActiveRecord настолько велики, что кэширование их нецелесообразно. Критичные атрибуты хранятся в хэше, а остальная их часть подвергается "ленивой загрузке" в момент запроса на доступ.
- 90% запросов являются запросами к API. Таким образом кэширование страниц или их фрагментов становится бессмысленным, зато никто не мешает им кэшировать сами API запросы.
Внутренняя организация работы с сообщениями:
- Сообщения очень активно используются: производители генерируют сообщения, они образуются в очереди, а затем распространяются по потребителем.
- Основная функция Twitter заключается в реализации своеобразного моста между различными форматами электронных сообщений (SMS, электронная почта, сервисы мгновенного обмена сообщениями и так далее).
- Чтобы инвалидировать в кэше информацию можно просто отправить внутреннее сообщение, зачем выполнять все действия синхронно?
- Изначально этот механизм основывался на DRb (distributed Ruby) - библиотека, позволяющая отправлять и принимать сообщения сообщения между удаленными Ruby-объектами по TCP/IP. Но она была несколько странноватой, да и являлось потенциально слабым местом с точки зрения стабильности.
- Со временем сервис перевели на Rinda, представляющую собой набор общих для всей системы очередей. Но и у нее были недостатки: все очереди были постоянными, а данные терялись при сбоях.
- Следующей попыткой был Erlang. Но однажды возникла проблема: каким образом сломавшийся сервер может продолжать работать, но при этом в очереди откуда-то возникли целых 20000 ожидающих пользователей? Разработчики не знали. На лицо явный недостаток документации...
- В конце концов решение было разработано своими силами: Twitter выпустил Starling, распределенный легковесный сервер очередей, написанный на Ruby и поддерживающий протокол memcache. Сейчас серверная часть Twitter управляется именно им.
- Распределенные очереди позволяют переживать сбои путем записи их на диск в критических ситуациях. Другие крупные интернет-проекты также часто пользуются таким подходом.
Работа с SMS осуществляется с помощью сторонних сервисов и предоставляемых ими шлюзов. Достаточно дорогое удовольствие.
Развертывание:
- Просто запускаются дополнительные сервера с mongrel, более элегантного решения пока нет.
- Все внутренние ошибки выдаются пользователям, если обслуживающий их mongrel сервер на данный момент заменяется.
- Все сервера останавливаются одновременно. Отключение их по одному по определенным причинам не используется.
Неправильное использование сервиса:
- Много времени сервис был не доступен, так как люди проходились специальными программами по сайту с целью добавить всех кто попадался под руку в друзья. 9000 друзей за 24 часа. Это просто-напросто останавливало работу сайта.
- Были разработаны средства для своевременного обнаружения таких ситуаций.
- Будте беспощадными, таких пользователей нужно просто удалять.
Сегментирование:
- Пока оно только в планах, сейчас оно не используется.
- В будущем оно будет основываться на времени, а не на пользователях, так как запросы обычно очень локальны по времени.
- Сегментирование будет не так просто реализовать благодаря автоматическому запоминанию результатов выполнения функций для последующего повторного их использования. Никто не даст гарантии, что операции "только для чтения" на самом деле будут таковыми являться. Запись в slave, работающий в режиме read-only, - не самая лучшая идея.
API Twitter генерирует в 10 раз больше трафика, чем сам сайт.
- Их API - самая важная вещь из всех, что они разработали.
- Простота сервиса позволила разработчикам строить свои приложения поверх инфраструктуры Twitter, привнося все новые и новые идеи. Например, Twitterrific - красивый способ использовать Twitter в небольшой команде.
Мониторинг используется для остановки слишком больших процессов.

Подводим итоги

Общайтесь со своим сообществом. Не прячьтесь и не пытайтесь решить абсолютно все проблемы самостоятельно. Много отличных людей будут готовы помочь, достаточно лишь попросить.
Рассматривайте вашу стратегию масштабирования как бизнес-план. Соберите советы помощников для того чтобы облегчить для себя принятие решений.
Стройте свой проект сами. Twitter потратил много времени, пытаясь приспособить готовые решения других людей, которые казалось бы должны работать, но это оказалось не совсем так. Лучше построить какие-то вещи самостоятельно, чтобы иметь высокую степень контроля над ситуацией и иметь возможность привносить новые возможности как только они понадобились.
Ставьте перед своими пользователями разумные ограничения. На обычных пользователей это не повлияет, но когда кому-нибудь взбредет в голову попытаться сломать систему (а такой человек рано или поздно найдется) - они сыграют свою роль и спасут работоспособность системы.
Не делайте базу данных центральным узким местом системы, врядли Ваше приложение на самом деле требует гигантских операций по объединению данных из нескольких таблиц. Используйте кэширование, или проявите свою смекалку для поиска альтернативных способов достижения того же результата.
Предусмотрите возможность сегментирования с самого начала, тогда перед Вами всегда будут открыты пути для дальнейшего масштабирования.
Очень важно вовремя осознать, что сайт начинает работать медленно. Сразу стоит задуматься о системе отчетов для отслеживания потенциальных проблем.
Оптимизируйте базу данных:
- Индексируйте все таблицы, Rails не будет делать это за Вас.
- Используйте "explain" для анализа выполнения запросов. Результаты могут не совпадать с Вашими ожиданиями.
- Денормализуйте данные. Один только этот совет порой может спасти ситуацию. Для примера, в Twitter хранят все ID друзей каждого пользователя вместе, это позволило избежать многих ресурсоемких запросов.
- Избегайте комплексного объединения данных из нескольких таблиц.
- Избегайте сканирования больших наборов данных.
Кэшируйте все, что только можно.
Тестируйте все максимально тщательно:
- Когда Вы развертываете приложение, Вы должно быть уверены, что оно будет работать корректно.
- Они используют полный набор средств для тестирования. Таким образом, когда произошла неполадка в кэшировании, они узнали о ней еще до того как она на самом деле произошла.
Длительно функционирующие процессы стоит оформить в виде daemon'ов.
Используйте уведомления об исключительных ситуациях в совокупности с ведением логов, это необходимо для своевременного реагирования на них.
Не делайте глупостей!
- Масштаб проект несколько меняет понятие "глупость".
- Пытаться загрузить 3000 друзей в память одновременно может заставить сервер временно перестать функционировать, хотя когда друзей было всего 4 - этот механизм прекрасно работал.
Большая часть производительности зависит не от использованного языка программирования, а от продуманной структуры приложения.
Превратите свой сайт в открытый сервис с помощью создания API. Их API является ключом к успеху Twitter. Он позволяет пользователям создавать постоянно расширяющуюся экосистему вокруг Twitter, соревноваться с которой не так-то просто. Вы никогда не сможете сделать столько же работы, сколько смогут Ваши пользователи для Вас, Вам просто не хватит креативных идей. Так что не стесняйтесь, откройте свое приложение и сделайте интеграцию Вашего приложения с другими максимально простой и удобной!