我看过来自Foursquare的Harry Heymann给BASE用户组做的关于Lift的演讲。在那个视频中，他提到了Lift作为statebase是如何不能很好地扩展的。
是真的吗?如果是，为什么呢?注意:我对状态基知之甚少。
我好像找不到谷歌了，我待会儿再找。当这个问题出现在Lift邮件列表上时，该框架的作者通常会回复一篇他不久前写的博客文章，其中解释了为什么Lift是有状态的，但同时如何将Lift用作无状态框架。
这是链接
David Pollack对这个问题有一个很好的回答，在对Jackson Davis的回答的评论中:
在实践中，扩展Lift站点要比扩展LAMP站点容易得多。为什么?状态存在于某个地方。如果它存在于JVM中，那么您可以获得很多性能优势和稳定性，并且在Lift的情况下，还可以获得很多安全性。与memcached中的会话形成对比。"哇，memcached坏了，有一堆会话掉了。"哎呀，我们有了一个新的memcached哈希算法，所有的会话都结束了。"哎呀，谷歌刚刚爬行了我们，创建了20万个新会话，将所有的会话都挤出了缓存。"哎呀，Ruby运行时失控了，吞噬了我们一台机器上的所有虚拟机，memcached崩溃了……"因此，您尝试将会话存储在一些古怪的MySQL共享版本中。这个解决方案需要大量的硬件和一个团队来确保共享代码是正确的等等。这与使用Nginx、Jetty和会话关联形成对比。大约需要4个小时的设置时间，它就可以工作了。见http://blog.harryh.org/post/7550..。所以，和Facebook工程师谈谈他们在管理前端、memcached、MySQL等之间的状态时遇到的挑战。将其与Twitter上著名的失败鲸进行比较。相比之下，苹果的商店和iTunes商店都是在WebObject上编写的(这是高度有状态的)。大规模运行的Lift应用程序通常需要LAMP应用程序7%的前端资源。大规模运行的Lift应用程序(Foursquare和Novell pulse是两个)不存在与具有类似流量模式的LAMP站点相关的扩展问题。使用Lift进行扩展既不复杂，也没有风险。这很简单。这是已知的。这是证明。使用LAMP进行扩展是在与状态玩打地鼠游戏，这只有在扩展时才会成为问题。——david Pollak, 2010年7月20日
我认为Lift应用的可扩展性非常好。Foursquare和英国卫报都在使用Lift。这两个站点的流量都非常高，而且都没有发生与lift相关的材料中断。也请参阅迭戈张贴的链接。它提供了扩展lift支持的站点的深入讨论。