Что значит сказать, что фреймворк “хорошо масштабируется”?

StackOverflow https://stackoverflow.com/questions/936461

  •  06-09-2019
  •  | 
  •  

Вопрос

Когда читаешь о фреймворках (.net.ruby on rails, django, spring и т.д.), Я продолжаю видеть, что so and so хорошо масштабируется или нет.

Что это значит, когда кто-то говорит, что фреймворк "хорошо масштабируется", и что значит сказать, что фреймворк "плохо масштабируется"?

Спасибо.

Это было полезно?

Решение

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

Небольшой масштаб - несколько пользователей - использует несколько ресурсов.

Крупномасштабный - большое количество пользователей - использует большое количество ресурсов.

Важнейший вопрос заключается в том, "насколько близко масштабирование к линейному?" Если он масштабируется линейно, то обслуживание 2000 одновременных пользователей обходится в 2 раза дороже, чем обслуживание 1000 пользователей, и в 4 раза дороже, чем обслуживание 500 пользователей.Это инструмент / фреймворк / язык / платформа / ОС, который хорошо масштабируется.Это предсказуемо, и предсказание линейно.

Если он не масштабируется линейно, то обслуживание 4000 пользователей обходится в 1000 раз дороже, чем обслуживание 2000 пользователей, что в 100 раз дороже обслуживания 500 пользователей.Это не очень хорошо масштабировалось.Что-то пошло не так по мере роста использования;это не кажется предсказуемым и не является линейным.

Другие советы

Это означает, что конкретный фреймворк удовлетворяет (или не удовлетворяет) возросшим требованиям, которые предъявляют к нему все больше пользователей.Например, если у вас есть приложение, написанное на VBScript, оно может плохо справляться с обработкой 40 000 000 пользователей Facebook.

Это сообщение в блоге объясняет некоторые проблемы с масштабируемостью, с которыми Twitter столкнулся примерно год назад.Это могло бы дать некоторое представление об ответе на ваш вопрос.

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

Если фреймворк или приложение хорошо масштабируются, это означает, что они могут выдерживать большие нагрузки.По мере того как ваш сайт становится все более популярным с большим количеством посетителей и просмотров в день, хорошо масштабируемый фреймворк будет справляться с большей нагрузкой так же, как и с меньшей.Хорошо масштабируемый фреймворк будет действовать так же, когда он получает 200 000 обращений в час, как и при получении 1 обращения в час.Не только попадает, но и развертывается на нескольких серверах, возможно, из-за балансировки нагрузки, возможно, на нескольких разных серверах баз данных.Хорошо масштабируемая платформа может хорошо справляться с этими растущими требованиями.

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

замените фразу "расширение дескриптора" на "масштабирование".

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

Второй вопрос - может ли ит масштабироваться для более крупных команд или предприятия.То есть, хорошо ли это работает с большими кодовыми базами?Большие команды разработчиков?Есть ли у него хорошая инструментальная поддержка?Насколько легко его развернуть?Можете ли вы охватить десятки, сотни или даже тысячи пользователей?Вплоть до того, легко ли нанять людей, обладающих этим навыком.Подумайте о попытке собрать команду разработчиков из 20 или 50 человек, которые все будут работать над этим фреймворком.Будет ли это легко или почти невозможно?

ИМХО, высказывание о том, что фреймворк "хорошо масштабируется", обычно означает, что кто-то в цепочке слухов смог использовать его для обработки большого объема.

В параллельном программировании масштабируемость обычно используется для описания того, как алгоритм работает при его распараллеливании.Алгоритм, который ускоряется 1: 1, является редким зверем, но увеличит производительность вдвое на удвоенном оборудовании / процессоре, утроит в три раза аппаратное обеспечение / процессор и т.д...

По моему опыту, практически любой фреймворк можно масштабировать при наличии достаточного опыта.

Чем проще фреймворк в использовании, тем больше вероятность того, что разработчик с недостаточным опытом столкнется с проблемами масштабируемости.

Это означает, что какая-то уважаемая компания занимается этим чем-то серьезным и у нее нет с этим никаких проблем.

Масштабирование означает, насколько легко удовлетворить больший спрос, используя больше оборудования.

Пример:У вас есть веб-сайт, написанный на каком-то языке, который получает 1000 посещений в день.Вас публикуют в каком-нибудь известном журнале, и число ваших пользователей растет.Внезапно у вас становится 1000000 посещений в день, это в 1000 раз больше.Если вы можете просто использовать еще 1000 серверов для удовлетворения возросшей потребности в ресурсах, ваш веб-сайт будет хорошо масштабироваться.С другой стороны, если вы добавляете 2000 серверов, но пользователи по-прежнему не могут подключиться, потому что ваша база данных может обрабатывать только 1000 запросов в день, то ваш веб-сайт плохо масштабируется.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top