Wicket: “large memory footprint!”, "Does Wicket scale?".. etc

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.

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.

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:

1. There's nothing Wicket stores in memory which you wouldn't have to store in memory anyway. It's just better organised, easier to develop, keep consistent, and test.
2. Java itself means that you're carrying some inevitable excess baggage around all the time. If they are so worried about footprint, maybe Java isn't the language they want to use at all. There are hundreds of large traffic websites written in other languages, so that's a perfectly workable solution. The worst thing they can do is to go with Java, take on the excess baggage and then not use the advantages that come with an advanced framework.

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:

1. http://fabulously40.com/ - social network with many users,
2. several education sites - I know two in USA and one in Netherlands. They also have quite a lot users,
3. currently I work on a project that expects to be used by several million users. Wicket 1.5 will be improved wherever we find hotspots.

Send this to your CTO ;-)