私はLift2.0がActorsやStatefulSnippetsなどでテーブルにもたらすものに非常に感銘を受けていますが、これらのもののメモリオーバーヘッドについて少し心配しています。私の質問は2つあります：
Webクローラーがサイトのフットプリント全体で踊る場合、適度なVPS（512M）をかき消すのに十分な状態オブジェクトを開く予定ですか？質問は明らかにアプリケーションに依存しますが、誰かが私に投げ出すことができる現実世界の数字を持っているかどうか私は興味があります。
Lift は状態情報をセッションに保存するため、セッションが破棄されると、そのセッションに関連付けられた状態は失われます。
Lift はセッション内で、状態が割り当てられている各ページを追跡し (例えば、ブラウザーの ajax ボタンとサーバーの機能の間のマッピング)、ブラウザーからのハートビートを受け取ります。10 分間ハートビートを確認していないページの関数は参照されないため、JVM はそれらをガベージ コレクションできます。これらはすべて調整可能であるため、ハートビートの頻度や関数の寿命などを変更できますが、実際にはデフォルトで十分に機能します。
セッションの爆発に関しては、ええ...それは小さな問題です。人気のサイト ( http://demo.liftweb.net/を含む) で体験できます。サンプル コード ( http://github.com/lift/lift/tree/master/examples/example/を参照) は、単一のリクエストによって作成されたセッションを検出し、その後放棄して早期に期限切れにします。私は 256MB のヒープ サイズ (512MB の VPS に収まる) で demo.liftweb.net を実行しています。時折、セッション数が 1,000 を超えますが、検索エンジンのトラフィックのためにすぐに減少します。
メモリ フットプリントに関する質問は、メーリング リストのどこかで回答があったと思いますが、現時点では見つかりません。
ガベージ コレクションは、アイドル時間の後に行われます。ただし、ウィキには、より優れたヒューリスティックを使用して、Web クローラーによって生成されたセッションを強制終了する例があります。
もちろん、自分のプロジェクトでは、VisualVM のようなものを使用してメモリ消費をチェックし、いくつかのセッションを自分で生成することは理にかなっています。