Wicket：“内存占用很大！”、“Wicket 是否可以扩展？”等等
Wicket 大量使用会话，这对于具有大量页面的大型应用程序来说可能意味着“大量内存占用”（如一些开发人员所述）。如果您要向财富 500 强的一群 CTO 解释他们必须为他们的大型网络采用 Apache Wicket应用程序部署以及他们对 Wicket 扩展问题的担忧只是错误的假设；你会争论什么？
PS：
- 问题仅涉及 缩放。
- 技术细节和现实世界 例子非常受欢迎。
Wicket uses the Session heavily which could mean “large memory footprint” (as stated by some developers) for larger apps with lots of pages. If you were to explain to a bunch of CTOs from Fortune 500 that they have to adopt Apache Wicket for their large web application deployments and that their fears about Wicket problems with scaling are just bad assumptions; what would you argue?
PS:
- The question concerns only
scaling. - Technical details and real world
examples are very welcomed.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
IMO 的 Apache Wicket 在超大规模部署中的可信度通过以下 URL 得到满足： http://mobile.walmart.com 查看源代码。
另请参阅http://mexico.com、http://vegas.com< /a>、http://adscale.de，然后使用 Alexa 查找这些域以查看其排名。
所以，是的，使用 Wicket 构建互联网规模的应用程序是很有可能的。但无论您是否使用 Wicket、Struts、SpringMVC，或者只是普通的旧式 JSP：互联网规模的软件开发都是困难。没有任何框架可以让您轻松做到这一点。没有任何框架可以为您提供具有为 500 万用户提供服务的下一步完成向导的软件。
IMO credibility for Apache Wicket in very large scale deployment is satisfied with the following URL: http://mobile.walmart.com View the source.
See also http://mexico.com, http://vegas.com, http://adscale.de, and look those domains up with alexa to see their ranking.
So, yes it is quite possible to build internet scale applications using Wicket. But whether or not you are using Wicket, Struts, SpringMVC, or just plain old JSPs: internet scale software development is hard. No framework can make that easy for you. No framework can give you software with a next-next-finish wizard that services 5M users.
好吧，首先解释一下足迹从哪里来，主要是
PageMap。下一步是解释页面映射的作用、用途以及解决什么问题（例如后退按钮和弹出对话框）。必须手动解决的问题，内存成本相似，但开发成本和风险要大得多。
最后，告诉他们如何影响页面映射、二级页面缓存中的内容，以及如何控制大小。
显然，您也可以向他们展示基准测试，但可能更好的选择是给 Martijn Dashorst 留言（尽管我相信他无论如何都会阅读这篇文章:)）。
无论如何，我会尝试强调两点：
Well, first of all, explain where the footprint comes from, and it is mainly the
PageMap.The next step would be to explain what a page map does, what is it for and what problems it solves (back buttons and popup dialogs for example). Problems, which would have to be solved manually, at similar memory costs but at a much bigger development cost and risk.
And finally, tell them how you can affect what goes in the page map, the secondary page cache and thus how the size can be kept under control.
Obviously you can also show them benchmarks, but probably an even better bet is to drop a line to Martijn Dashorst (although I believe he's reading this post anyway :)).
In any case, I'd try to put two points across:
Wicket 保存会话中的最后 N 页。这样做是为了能够在需要时更快地加载页面。主要在两种情况下需要它 - 使用浏览器后退按钮或在 Ajax 应用程序中。
后退按钮很清楚，我想不需要解释。
关于Ajax - 每个ajax请求都需要当前页面（会话缓存中的最后一个页面）来查找其中的组件并调用其回调方法，更新某些模型等。
从他们看来，会话大小完全取决于您的应用程序代码。对于任何 Web 框架来说都是一样的。
要缓存的页面数量（上面的 N）是可配置的，即根据您的应用程序的类型，您可以根据需要进行调整。即使没有内存缓存（N = 0），页面也会存储在磁盘中（再次可配置）并且将再次找到该页面，只是速度会慢一些。
关于一些参考资料：
将此发送给您的首席技术官；-)
Wicket saves the last N pages in the session. This is done to be able to load the page faster when it is needed. It is needed mostly in two cases - using browser back button or in Ajax applications.
The back button is clear, no need to explain, I think.
About Ajax - each ajax requests needs the current page (the last page in the session cache) to find a component in it and call its callback method, update some model, etc.
From their on the session size completely depends on your application code. It will be the same for any web framework.
The number of pages to cache (N above) is configurable, i.e. depending on the type of your application you may tweak it as your find appropriate. Even when there is no inmemory cache (N=0) the pages are stored in the disk (again configurable) and the page will be find again, just it will be a bit slower.
About some references:
Send this to your CTO ;-)