Почему лифтовая платформа масштабируема?

Question

Я хочу знать технические причины, по которым лифтовая веб-конструкция имеет высокую производительность и масштабируемость? Я знаю, что он использует Scala, которая имеет библиотеку актеров, но согласно инструкциям по установке, это конфигурация по умолчанию с Jetty. Так использует ли она библиотеку актеров для масштабирования?

Теперь масштабируемость встроена прямо из коробки. Просто добавьте дополнительные серверы и узлы, и он автоматически масштабируется, это так? Может ли он обрабатывать более 500000 одновременных соединений с поддерживающими серверами.

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

Спасибо

Answer 1

Подход Lift к масштабируемости лежит на одной машине. Масштабирование на разных машинах - более сложная тема. Краткий ответ: Scala и Lift ничего не делают, чтобы помочь или препятствовать горизонтальному масштабированию.

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

Типичная структура использует поток для обслуживания запроса страницы. Когда клиент подключается, платформа назначает поток из пула. Затем этот поток выполняет три вещи: он читает запрос из сокета; он выполняет некоторые вычисления (потенциально включая ввод-вывод в базу данных); и он отправляет ответ на сокет. Практически на каждом этапе поток будет блокироваться в течение некоторого времени. При чтении запроса его можно заблокировать во время ожидания сети. При выполнении вычислений он может блокировать дисковый или сетевой ввод-вывод. Он также может заблокировать во время ожидания базы данных. Наконец, при отправке ответа он может блокироваться, если клиент получает данные медленно и окна TCP заполняются. В целом, поток может потратить 30 - 90% своего времени заблокированного. Однако он тратит 100% своего времени на один запрос.

JVM может поддерживать только столько потоков, сколько реально замедляется. Планирование потоков, конкуренция за объекты общей памяти (например, пулы соединений и мониторы) и собственная ОС ограничивают все ограничения на количество потоков, которые может создать JVM.

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

(Существуют и другие проблемы, которые могут накладывать более низкие ограничения - например, GC thrashing. Потоки являются основным ограничивающим фактором, но не единственным!)

Lift отделяет поток от запросов. В Lift запрос не связывает поток. Скорее, поток выполняет действие (например, читает запрос), а затем отправляет сообщение субъекту. Актеры - важная часть истории, потому что они запланированы через «легкие» темы. Пул потоков используется для обработки сообщений внутри актеров. Важно избегать блокирования операций внутри акторов, поэтому эти потоки быстро возвращаются в пул. (Обратите внимание, что этот пул не виден приложению, он является частью поддержки акторов в Scala.) Например, запрос, который в настоящее время заблокирован для базы данных или дискового ввода-вывода, не удерживает поток обработки запросов занятым. Поток обработки запросов доступен почти сразу, чтобы получить больше соединений.

Этот метод для разделения запросов от потоков позволяет серверу Lift иметь намного больше одновременных запросов, чем сервер потока на запрос. (Я также хотел бы отметить, что библиотека Grizzly поддерживает аналогичный подход без акторов.) Больше одновременных запросов означает, что один сервер Lift может поддерживать больше пользователей, чем обычный сервер Java EE.

Answer 2

у mtnyguard

«Scala и Lift не делают ничего, чтобы помочь или препятствовать горизонтальному масштабированию»

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

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

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

Answer 3

Возможно, Jetty является точкой входа, но актер заканчивает тем, что обслуживает запрос, я предлагаю взглянуть на пример в стиле твиттера 'skitter', чтобы увидеть, как вы сможете создать очень масштабируемый сервис. IIRC, это одна из вещей, которая привлекла внимание твиттеров.

Answer 4

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

Проблема - Вместо того, чтобы снова описывать все это, ознакомьтесь с обсуждением (а не с содержанием) этого поста. http://javasmith.blogspot.com/2010/02/automagically-cluster-web-sessions-in.html

Решение будет таким, как @dre сказал, что липкая конфигурация сеанса на балансировщике нагрузки спереди и добавление дополнительных экземпляров Но так как обработка запросов в lift выполняется в комбинации потоков и акторов, вы можете ожидать, что один экземпляр обработает больше запросов, чем обычные платформы. Это дало бы преимущество над наличием липких сессий в других структурах. то есть способность отдельного экземпляра обрабатывать больше может помочь вам масштабировать

• у вас есть интеграция с Akka lift, которая была бы еще одним преимуществом в этом.