почему веб-платформа лифта масштабируема?
Интересный вопрос. Вы можете найти FAQ о хуках полезным, так как я думаю, что он довольно конкретно отвечает на ваш вопрос.
В вашем первом примере ваш несмонтированный var является частью свойств вашего компонента, а во втором примере он просто выбирается как часть закрытия javascript.
Обычно вы хотите убедиться, что изменили смонтированный параметр как часть метода жизненного цикла componentDidUnmount.
Я думаю, что если вы добавите unmounts в список зависимостей, это может сработать? Обычно я использую реагирование из другого фреймворка в Clojurescript, так что я не совсем знаком с семантикой основного интерфейса javascript, но по крайней мере это было бы причиной того, почему вы получаете предупреждение для первого примера.
В вашем первом примере, что произойдет, если вы измените последнюю часть на следующую?
useEffect(() => {
return () => {
unmounted = true;
};
}, [unmounted]);
}
Возможно, вам потребуется определить unmounts как более формальное свойство реагирования, а не просто заключенное свойство в вашем компоненте.
4 ответа
Причал, возможно, точка входа, но агент заканчивает тем, что обслужила запрос, я предлагаю взглянуть на пример Твиттера-esque, 'несусь', чтобы видеть, как Вы смогли бы создать очень масштабируемый сервис. IIRC, это - одна из вещей, которые заставили людей Твиттера заметить.
Подход Lift к масштабируемости заключается в одной машине. Масштабирование на разных машинах - более сложная тема. Краткий ответ таков: Scala и Lift не делают ничего, чтобы помочь или препятствовать горизонтальному масштабированию.
Что касается акторов в одной машине, Lift достигает лучшей масштабируемости, потому что один экземпляр может обрабатывать больше параллельных запросов, чем большинство других сервера. Чтобы объяснить, я сначала должен указать на недостатки в классической модели обработки потоков на запрос. Имейте в виду, это потребует некоторого объяснения.
Типичная структура использует поток для обслуживания запроса страницы. Когда клиент подключается, платформа назначает поток из пула. Затем этот поток выполняет три вещи: он читает запрос из сокета; он выполняет некоторые вычисления (потенциально включая ввод-вывод в базу данных); и он отправляет ответ на сокет. Практически на каждом этапе поток будет блокироваться в течение некоторого времени. При чтении запроса его можно заблокировать во время ожидания сети. При выполнении вычислений он может блокировать дисковый или сетевой ввод-вывод. Он также может заблокировать во время ожидания базы данных. Наконец, при отправке ответа он может блокироваться, если клиент получает данные медленно и окна TCP заполняются. В целом поток может потратить 30 - 90% своего времени заблокированного. Однако он тратит 100% своего времени на этот один запрос.
JVM может поддерживать только столько потоков, пока он действительно не замедлится. Планирование потоков, конкуренция за объекты общей памяти (например, пулы соединений и мониторы), а собственная ОС ограничивает все налагаемые ограничения на количество потоков, которые может создать JVM.
Что ж, если JVM ограничена в максимальном количестве потоков, а количество потоков определяет, сколько одновременных запросов может обработать сервер, тогда количество одновременных запросов будет определяться количеством потоков.
(Существуют и другие проблемы, которые могут налагать более низкие ограничения - например, перебор GC. Потоки являются основным ограничивающим фактором, но не единственным!)
Lift отделяет поток от запросов. В Lift запрос не связывает нить. Скорее, поток выполняет действие (например, читает запрос), а затем отправляет сообщение субъекту. Актеры - важная часть истории, потому что они запланированы через «легкие» темы. Пул потоков используется для обработки сообщений внутри актеров. Это' Важно избегать блокирования операций внутри акторов, поэтому эти потоки быстро возвращаются в пул. (Обратите внимание, что этот пул не виден приложению, он является частью поддержки акторов в Scala.) Например, запрос, который в настоящее время заблокирован для базы данных или дискового ввода-вывода, не удерживает поток обработки запросов занятым. Поток обработки запросов почти мгновенно доступен для получения большего количества соединений.
Этот метод для отделения запросов от потоков позволяет серверу Lift иметь намного больше одновременных запросов, чем сервер потока на запрос. (Я также хотел бы отметить, что библиотека Grizzly поддерживает аналогичный подход без акторов.) Больше одновременных запросов означает, что один сервер Lift может поддерживать больше пользователей, чем обычный сервер Java EE.
поэтому эти потоки быстро возвращаются в пул. (Обратите внимание, что этот пул не виден приложению, он является частью поддержки акторов в Scala.) Например, запрос, который в настоящее время заблокирован для базы данных или дискового ввода-вывода, не удерживает поток обработки запросов занятым. Поток обработки запросов почти мгновенно доступен для получения большего количества соединений.Этот метод для отделения запросов от потоков позволяет серверу Lift иметь намного больше одновременных запросов, чем сервер потока на запрос. (Я также хотел бы отметить, что библиотека Grizzly поддерживает аналогичный подход без акторов.) Больше одновременных запросов означает, что один сервер Lift может поддерживать больше пользователей, чем обычный сервер Java EE.
поэтому эти потоки быстро возвращаются в пул. (Обратите внимание, что этот пул не виден приложению, он является частью поддержки акторов в Scala.) Например, запрос, который в настоящее время заблокирован для базы данных или дискового ввода-вывода, не удерживает поток обработки запросов занятым. Поток обработки запросов почти мгновенно доступен для получения большего количества соединений.Этот метод для отделения запросов от потоков позволяет серверу Lift иметь намного больше одновременных запросов, чем сервер потока на запрос. (Я также хотел бы отметить, что библиотека Grizzly поддерживает аналогичный подход без акторов.) Больше одновременных запросов означает, что один сервер Lift может поддерживать больше пользователей, чем обычный сервер Java EE.
это часть поддержки акторов в Scala.) Запрос, который в настоящее время заблокирован, например, для базы данных или дискового ввода-вывода, не занимает занятый поток обработки запросов. Поток обработки запросов почти мгновенно доступен для получения большего количества соединений.Этот метод для отделения запросов от потоков позволяет серверу Lift иметь намного больше одновременных запросов, чем сервер потока на запрос. (Я также хотел бы отметить, что библиотека Grizzly поддерживает аналогичный подход без акторов.) Больше одновременных запросов означает, что один сервер Lift может поддерживать больше пользователей, чем обычный сервер Java EE.
это часть поддержки акторов в Scala.) Запрос, который в настоящее время заблокирован, например, для базы данных или дискового ввода-вывода, не занимает занятый поток обработки запросов. Поток обработки запросов почти мгновенно доступен для получения большего количества соединений.Этот метод для отделения запросов от потоков позволяет серверу Lift иметь намного больше одновременных запросов, чем сервер потока на запрос. (Я также хотел бы отметить, что библиотека Grizzly поддерживает аналогичный подход без акторов.) Больше одновременных запросов означает, что один сервер Lift может поддерживать больше пользователей, чем обычный сервер Java EE.
почти сразу, чтобы получить больше соединений.Этот метод для разделения запросов от потоков позволяет серверу Lift иметь намного больше одновременных запросов, чем сервер потока на запрос. (Я также хотел бы отметить, что библиотека Grizzly поддерживает аналогичный подход без акторов.) Больше одновременных запросов означает, что один сервер Lift может поддерживать больше пользователей, чем обычный сервер Java EE.
почти сразу, чтобы получить больше соединений.Этот метод для разделения запросов от потоков позволяет серверу Lift иметь намного больше одновременных запросов, чем сервер потока на запрос. (Я также хотел бы отметить, что библиотека Grizzly поддерживает аналогичный подход без акторов.) Больше одновременных запросов означает, что один сервер Lift может поддерживать больше пользователей, чем обычный сервер Java EE.
at mtnyguard
"Scala и Lift не делают ничего, чтобы помочь или помешать горизонтальному масштабированию"
Не совсем верно. Lift - фреймворк с высокой степенью статичности. Например, если пользователь запрашивает форму, то он может отправить запрос только на ту же машину, с которой пришла форма, потому что действие по обработке формы сохраняется в состоянии сервера.
И это на самом деле вещь, которая в некотором смысле препятствует масштабируемости, потому что такое поведение не соответствует архитектуре shared nothing.
Без сомнения, lift обладает высокой производительностью, но производительность и масштабируемость - это две разные вещи. Поэтому, если вы хотите горизонтально масштабироваться с помощью lift, вы должны определить липкие сессии на балансировщике нагрузки, который будет перенаправлять пользователя во время сессии на ту же машину.
Мне очень нравится ответ @dre, поскольку он правильно заявляет, что состояние подъемной силы является потенциальной проблемой для горизонтальной масштабируемости.
Проблема - Вместо того, чтобы снова описывать все это, ознакомьтесь с обсуждением (а не с содержанием) этого поста. http://javasmith.blogspot.com/2010/02/automagically-cluster-web-sessions-in.html
Решение будет таким, как сказал @dre, липкая конфигурация сеанса на балансировщике нагрузки на передней панели и добавление дополнительных экземпляры. Но поскольку обработка запросов при подъеме выполняется в комбинации поток + субъект, можно ожидать, что один экземпляр будет обрабатывать больше запросов, чем обычные фреймворки. Это даст преимущество перед липкими сессиями в других фреймворках. т.е. способность отдельного экземпляра обрабатывать больше может помочь вам масштабировать
- , у вас есть интеграция с лифтом Akka, что было бы еще одним преимуществом в этом.