Как Scala Lift управляет состоянием?
Я весьма впечатлен тем, что Lift 2.0 вносит в таблицу с Actors, StatefulSnippets и т. Д., Но меня немного беспокоит нехватка памяти этих вещей. Мой вопрос двоякий:
- Как Lift определяет, когда собирать мусор для объектов состояния?
- Как выглядит объем памяти для запроса страницы?
Если веб-сканер танцует по всей площади сайта, они собираются открываться? Достаточно ли объектов состояния, чтобы заглушить скромный VPS (512M)? Вопрос, очевидно, зависит от приложения, но мне любопытно, есть ли у кого-нибудь цифры из реального мира, которые они могут бросить в меня.
2 ответа
Lift сохраняет информацию о состоянии в сеансе, поэтому после уничтожения сеанса состояние, связанное с этим сеансом, исчезает.
В рамках сеанса Lift отслеживает каждую страницу, для которой выделено состояние (например, сопоставление между кнопкой ajax в браузере и функцией на сервере), и отслеживает сердцебиение в браузере. На функции для страниц, которые не видели пульса в течение 10 минут, ссылки не выполняются, поэтому JVM может выполнить сборку мусора для них. Все это настраивается, поэтому вы можете изменять частоту сердечных сокращений, продолжительность работы функции и т. Д., Но на практике настройки по умолчанию работают довольно хорошо.
Если говорить о росте сеансов, да ...это второстепенная проблема. Популярные сайты (включая http://demo.liftweb.net/ ) испытывают это. Пример кода (см. http://github.com/lift/lift/tree/master/examples/example/ ) обнаруживает сеансы, которые были созданы одним запросом, а затем прерваны, и истекает раньше. Я использую demo.liftweb.net с размером кучи 256 МБ (что соответствует 512 МБ VPS), и иногда количество сеансов превышает 1000, но это быстро сокращается для трафика поисковых систем.
Я думаю, что на вопрос о площади памяти был дан ответ где-то в списке рассылки, но сейчас я не могу его найти.
Сборка мусора выполняется после некоторого времени простоя. Однако в вики есть пример, который использует несколько лучших эвристик для уничтожения сессий, порожденных веб-краулерами.
Конечно, для вашего собственного проекта имеет смысл проверить потребление памяти с помощью чего-то вроде VisualVM, самостоятельно породив пару сессий.