Hi Eelco, You are correct - right now my main worry is about development cost. Hardware cost is cheaper IMHO than having developers struggle with a hard framework and spending too much time trying to maintain and write code based around a hard framework.
Honestly in our application (we have a roadmap for scalability) we are likely to get several hundred concurrent sessions per server with a few kb of state stored in the HTTPSession. Its not that much. What I was more concerned about was Page storage and storage that I can't control (for example, if I couldn't control IModel storage I would be concerned). We are unlikely to have spikes of traffic, but we are more likely to have dribs and drabs of users who potentially keep sessions open for perhaps minutes to hours. For our initial scaling the client will have an affinity to a specific server. We can control the number of users that we have on a server. We can then scale our servers horizontally if we hit a scaling issue on one of the servers. I'm starting not to worry about it too much. Honestly - I really face the same issues with Tapestry. What I don't face with Wicket is the development cost because it appears to be (I played with it yesterday) a very intelligent architecture. I was happy playing yesterday and even migrated our login page over very quickly. Of course I have to figure out how to handle my 'remember me' cookie and hit the database, but it all seems rather nice. Cheers, Graeme. Eelco Hillenius wrote: > >>> I have a complex table and many links on the page that are not >>> book-markable. Will that be a problem in terms of too much session >>> information? > > The default session store in Wicket saves history in some temp files > and only holds the current page in memory (well, the current page of > any page map in case you use more). Say that's a very heavy page, > taking up to 100K. And say you run a VM with 1 GB of dedicated memory. > You can support close to 10,000 concurrent sessions (close, because > obviously, you'll use memory for other things than just sessions). > Changes are that you run into bottlenecks with processors and database > utilization long before you run out of memory for one box. > > The only kind of web sites I probably wouldn't recommend Wicket as > used by default for are sites like Google, Yahoo and CNN etc, where > you can have enormous spikes in traffic that are very short lived. > But... the good news with Wicket then again is that you can build your > app entirely using bookmarkable pages (even stateless if you want, so > that you can avoid *any* memory usage) so that clustering will be easy > and cheap. On top of that, you can plug in your own implementations of > things like session store so that you can decide when/ how/ where > state should be kept. > > You have to weigh the benefits of the stateful programming model > against your technical requirements. But you can use Wicket for most > use cases if you give it a bit of thought. > >>> Would it be conceptually easy for me to write Javascript/AJAX and hook >>> them into Wicket in a simple way? > > Yeah, that's fairly simple. You can either write snippets that are > used by components/ behaviors that integrate with our regular AJAX > engine, or you can even plugin your own engine if you'd prefer that. > >>> Its all about cost. > > The funny thing is that in most discussions out there people focus on > the cost of servers/ memory/ etc. While probably for most people - > basically for anything that doesn't have the size of Google - > development and maintenance cost is often the highest component. So a > good development model makes sense. > >>> we have absolute faith that it will have a lot of users according to our >>> business plan. > > May I ask what you think is a lot (say hits per second and concurrent > sessions)? Thousands? Tens of thousands? Hundred of thousands? Even > millions? If you're talking about really large numbers, you need to be > aware of the choices you make in your app, not only for Wicket > obviously, and test for scalability from the start. Though if you're > talking about thousands up to maybe a few thousands, Wicket should be > able to handle it fine without you having to worry about using > stateful components. > > Eelco > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Moving-from-Tapestry-to-Wicket--tp20254394p20291214.html Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
