В какой момент масштабируемость становится проблемой для приложения Rails, развернутого на Heroku?
Ruby on Rails в большинстве случаев ошибочно объясняется отсутствием возможностей масштабирования, и альтернатива обычно заключается в переносе в какую-либо форму Java Webapp или что-то подобное. Но все проблемы кажутся очень произвольными в лучшем случае, в некотором роде.
Существуют ли какие-либо конкретные числа для того, когда какое-либо приложение нужно переписать на другом языке? Heroku предоставляет различные варианты масштабирования с количеством динамиков, доступных для приложения, но в какой момент будет уменьшаться отдача, если таковая имеется, очевидна? Или в какой момент стоимость того, чтобы столько динамиков перевешивала затраты на простое создание нового приложения?
Сколько активных одновременных пользователей я могу ожидать, чтобы поддерживать их без проблем с производительностью на базовом бесплатном хостинговом плане в Heroku?
Ответы
Ответ 1
"Rails не масштабирует" миф просто не умрет...
Цитата ведущего архитектора Twitter:
Повышение производительности, связанное с "более быстрым" языком, даст нам 10-20% -ное улучшение, но благодаря архитектурным изменениям, которые Ruby и Rails с радостью разместили, Twitter на 10000% быстрее.
Я не могу дать вам фиксированное число, но почти полностью гарантировано, что вы столкнетесь с узкими местами в базе данных или архитектурой задолго до того, как Ruby или Rails начнут быть узкими местами.
Тефлон Тед создал хорошую коллекцию сообщений в блоге относительно этой темы,
