У сайтов Ruby on Rails проблемы с производительностью?

Ответ 1

Да, на сайтах Ruby on Rails есть проблемы с производительностью, как и на любом другом сайте. И точно так же, как и на любом другом сайте, эта производительность почти всегда уходит корнями в архитектурные решения, а не на язык или фреймворк.

Было ли приятное представление пару лет назад Joyent (возможно, это RailsConf 2007?), который показал на одном слайде все серверы, которые работают на одном экземпляре своей платформы Rails. Около 40 процессов. Только один из этих процессов был интерпретатором Ruby, все остальное было таким, как DNS-резольвер, веб-сервер, сервер базы данных, MTA, memcached, очередь сообщений, обратный прокси-сервер, балансировщик нагрузки и т.д. Каждый из них может испортить вашу производительность, Это 97,5% вероятность того, что ваши проблемы с производительностью не имеют ничего общего с Rails или Ruby.

Там есть несколько действительно хороших электронных писем в почтовых списках JRuby, а также некоторые твиты и сообщения в блогах от людей, которые переписывали свои веб-приложения Java в Ruby и получили 10% -ное улучшение производительности.

На самом деле хорошим примером является Twitter. Twitter - один из крупнейших сайтов Ruby on Rails в мире. Это также один с очень необычным шаблоном использования, который даст любую инфраструктуру, предназначенную для "нормальных" веб-приложений, для жесткой гайки.

Теперь вы можете подумать, почему я выбрал Twitter всех вещей как пример производительности и масштабирования, когда ясно, что это полная противоположность тому, что они известны? Что ж, это точно: у них была масса проблем масштабирования, производительности и надежности. И ни один из них не имел ничего общего с Rails или Ruby. Фактически, Rails и Ruby были в значительной степени единственными частями в их стеке, с которыми у них не было проблем.

У них были проблемы с неожиданным ростом. Неважно, какой язык или структура вы используете: если пользователи подписываются быстрее, чем вы можете купить новые серверы, вы ничего не можете сделать.

У них были проблемы с производительностью и масштабируемостью MySQL. Опять же, MySQL не имеет ничего общего с Rails или Ruby. Фактически, MySQL написан на C, поэтому, если вы действительно должны сделать какие-либо смешные выводы о языке программирования, основанные исключительно на одном инциденте, тогда это будет следующим: C медленный. Если вы хотите работать, держитесь подальше от C.

(В этом конкретном случае в одном из интервью они действительно винили Rails: они сказали, что, поскольку Rails поддерживает только одно подключение к одной базе данных, их экземпляр MySQL просто перегружен. В течение нескольких часов после того, как это интервью было опубликовано, два Rails разработчики, независимо друг от друга, выпустили плагины Rails для реализации нескольких подключений. Урок: только 80% решений находятся в ядре. Twitter явно не в 80%. API-интерфейс плагина существует по какой-то причине.)

У них были проблемы с производительностью и масштабируемостью всей системы. Оказалось, что для того, чтобы быстро получить продукт, они абсолютно не использовали кэширование. Даже "статическая" домашняя страница Twitter полностью динамически генерировалась для каждого отдельного запроса. Опять же, это не имело никакого отношения к Rails или Ruby. Вы можете принести любой сайт, отключив свои кеши, я вам это гарантирую.

Они затронули некоторые очень плохие проблемы масштабируемости (и упомянутые выше проблемы MySQL связаны с этим), которые были просто вызваны тем фактом, что люди использовали сайт так, как этого не ожидали разработчики. Всем известно, что Twitter - это платформа для обмена мгновенными сообщениями. Ну, кроме основателей Twitter. У них была эта блестящая идея для системы управления микросортированием.

Итак, они создали микро-CMS. И, конечно же, центральная часть системы управления контентом - это репозиторий контента, IOW - база данных. Однако пользователи использовали Twitter как платформу для обмена сообщениями. Центральным элементом платформы обмена сообщениями является очередь сообщений.

В результате MySQL использовался как очередь сообщений. Никакие две вещи не могут быть отделены друг от друга, кроме базы данных (особенно базы данных SQL) и очереди сообщений. Эти два имеют почти совершенно противоположные требования и ограничения.

И, конечно же, вся архитектура была построена вокруг этого репозитория контента, который теперь злоупотреблялся как очередь сообщений.

В ответ на это разработчики Twitter создали собственную очередь сообщений в Ruby, что помогло повысить производительность и масштабируемость. Но недостаточно. Итак, они написали очередную очередь сообщений, на этот раз в Scala.

Именно этот единственный переписывающий процесс несет полную ответственность за то, что я оценил бы 70% всего Rails FUD. Но я не знаю о вас: когда я пишу что-то, что я совершенно не знаю, как его написать, а затем я пишу то же самое во второй раз, когда я действительно знаю, что я делаю, и hellip; второй всегда лучше первого. И я подозреваю, что это тоже так.

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

Короче говоря: сегодня Twitter использует Ruby on Rails для того, что он должен был использовать: для веб-приложения. И они используют базу данных для хранения данных, а не как очередь сообщений. И они используют фактическую правильную очередь сообщений. Очередь сообщений и некоторые другие бэкэнда записываются в Scala. Интерфейс написан на Ruby on Rails. Некоторые вещи написаны на C.

И все персик.

Настоящая мораль истории здесь заключается в том, что вы можете заменить практически любое большое веб-приложение, любой язык, любую структуру в вышеупомянутую историю, и это все равно будет правдой. MySpace - один из самых медленных и ненадежных сайтов, которые я знаю, и это сайт .NET. GitHub - один из самых быстрых сайтов, которые я знаю, будучи крупнейшей хостинговой платформой (у нее более миллиона репозиториев после чуть более двух лет, что больше, чем SourceForge и Google Code) и написано в Ruby on Rails для интерфейса, Sinatra для веб-сервиса, Ruby для интерфейса Git и инфраструктуры Git, Erlang для федерации и облачной инфраструктуры и Node.JS для сервера загрузки.

Ответ 2

Здесь начинается

Масштабирование ROR

Почему Rails может работать медленно

Сравнение производительности платформы

Связанный с нами вопрос

Связанная статья интереса Twitter оставляет ROR свой старый я знаю, но я действительно не знал, что lol

Короткий ответ
Мог бы быть уверенным.

Может быть более вероятным, чем некоторые другие языки.
Зависит от приложения, программиста и архитектуры.

Ответ 3

Как я вижу - RoR только немного медленнее. По крайней мере, медленнее, чем .Net, рубинский язык интерпретируется.

Но в целом - это зависит от качества разработчиков. Приложение RoR, использующее красивое кэширование, будет работать в разы быстрее, чем приложение .net/java, которое загружает половину базы данных в память и отправляет множество запросов к базе данных из select n+1.

Ответ 4

да, это медленнее, но в производстве это, вероятно, только повредит вам, когда ваш груз "превысит определенную точку" ( "x запросов/сек" ), и большинство сайтов никогда не видят больше нагрузки.