Scala 的 Lift 如何管理状态？
Lift 2.0 带来的 Actors 和 StatefulSnippets 等给我留下了深刻的印象，但我有点担心这些东西的内存开销。我的问题有两个：
- Lift 如何确定何时垃圾收集状态对象？
- 页面请求的内存占用是什么样的？
如果网络爬虫在网站的足迹上跳舞，他们是否会打开足够的状态对象来淹没一个普通的 VPS (512M)？这个问题显然取决于应用程序，但我很好奇是否有人有任何可以向我抛出的真实世界数据。
I'm quite impressed by what Lift 2.0 brings to the table with Actors and StatefulSnippets, etc, but I'm a little worried about the memory overhead of these things. My question is twofold:
- How does Lift determine when to garbage collect state objects?
- What does the memory footprint of a page request look like?
If a web crawler dances across the footprint of the site, are they going to be opening up enough state objects to drown out a modest VPS (512M)? The question is very obviously application dependent, but I'm curious if anyone has any real world figures they can throw out at me.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Lift 将状态信息存储在会话中，因此一旦会话被销毁，与该会话关联的状态就会消失。
在会话中，Lift 跟踪为其分配状态的每个页面（例如，浏览器中的 ajax 按钮与服务器上的功能之间的映射）并获得来自浏览器的心跳。 10 分钟内没有看到心跳的页面的函数不会被引用，因此 JVM 可以对它们进行垃圾回收。所有这些都是可调的，因此您可以更改心跳频率、功能寿命等，但实际上默认值效果很好。
就会话爆炸而言，是的......这是一个小问题。热门网站（包括 http://demo.liftweb.net/ ）体验它。示例代码（请参阅 http://github.com/lift/lift/tree /master/examples/example/ ）检测由单个请求创建然后放弃并提前过期的会话。我正在运行 demo.liftweb.net，堆大小为 256MB（适合 512MB VPS），偶尔会话计数会增加超过 1,000，但很快就会因搜索引擎流量而被抑制。
Lift stores state information in a session, so once the session is destroyed the state associated with that session goes away.
Within the session, Lift tracks each page that state is allocated for (e.g., mapping between an ajax button in the browser and a function on the server) and have a heart-beat from the browser. Functions for pages that have not seen the heartbeat in 10 minutes are unreferenced so the JVM can garbage collection them. All of this is tunable, so you can change heart-beat frequency, function lifespan, etc., but in practice the defaults work quite well.
In terms of session explosion, yeah... that's a minor issue. Popular sites (including http://demo.liftweb.net/ ) experience it. The example code (see http://github.com/lift/lift/tree/master/examples/example/ ) detects sessions that were created by a single request and then abandoned and expires those early. I'm running demo.liftweb.net with 256MB of heap size (that'd fit in a 512MB VPS) and occasionally, the session count rises over 1,000, but that's quickly tamped down for search engine traffic.
我认为有关内存占用的问题曾经在邮件列表中的某个地方得到过解答，但目前我找不到它。
垃圾收集是在一段空闲时间后完成的。然而，维基百科上有一个 示例，它使用了一些更好的启发式方法杀死网络爬虫产生的会话。
当然，对于您自己的项目，在自己生成几个会话时使用 VisualVM 等工具检查内存消耗是有意义的。
I think the question about memory footprint was once answered somewhere on the mailing list, but I can’t find it at the moment.
Garbage collection is done after some idle time. There is, however, an example on the wiki which uses some better heuristics to kill off sessions spawned by web crawlers.
Of course, for your own project it makes sense to check memory consumption with something like VisualVM while spawning a couple of sessions yourself.