Re: Page pooling (for stateless pages)
stateless != static, though If you cache the results of a stateless page, you could show stale information from the database, correct? On Mon, May 19, 2008 at 1:18 AM, Erik van Oosten [EMAIL PROTECTED] wrote: Hello, I think it would probably make more sense to cache the /result/ of stateless pages. Regards, Erik. Joel Halbert wrote: Hi, I was wondering whether it was possible to implement pooling of stateless pages? Possibly using a custom PageMap implementation? Although newer JVM's are good at performing GC, pooling is a reasonable additional technique to use for achieving that extra bit of scalability. If anyone has tried to do this, or has any suggestions on the best way forward I'd be really interested to know. Many Thanks, Joel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page pooling (for stateless pages)
On Sun, May 18, 2008 at 11:04 PM, James Carman [EMAIL PROTECTED] wrote: stateless != static, though If you cache the results of a stateless page, you could show stale information from the database, correct? True, so it depends on your use case. And obviously it wouldn't work for form processing either. But for - say - a catalogue site where hourly updates are good enough (in which case you would invalidate the cache every hour), it might be an option. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page pooling (for stateless pages)
In our use case all the pages are stateless, but they are by no means static. We have in fact designed the entire site to use stateless pages, again for scalability; but every single page is also dynamic. I would like to produce and share some metrics from the JVM around object allocation and collection for a wicket application that is under sustained load using JMeter, and will do so as and when these become available. If anyone has any concise testing strategies along these lines please share them Joel -- From: Eelco Hillenius [EMAIL PROTECTED] Sent: Monday, May 19, 2008 7:18 AM To: users@wicket.apache.org Subject: Re: Page pooling (for stateless pages) On Sun, May 18, 2008 at 11:04 PM, James Carman [EMAIL PROTECTED] wrote: stateless != static, though If you cache the results of a stateless page, you could show stale information from the database, correct? True, so it depends on your use case. And obviously it wouldn't work for form processing either. But for - say - a catalogue site where hourly updates are good enough (in which case you would invalidate the cache every hour), it might be an option. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page pooling (for stateless pages)
Hi, first of all, I don't really think it's worth pooling pages. I can't imagine that page instance creation would have that much overhead. Also stateless pages doesn't mean they don't contain any state. The page is stateless because it's not kept between requests, but during request there's lot going on with the page. So you can't just reuse the instances. -Matej On Sun, May 18, 2008 at 1:10 PM, Joel Halbert [EMAIL PROTECTED] wrote: Hi, I was wondering whether it was possible to implement pooling of stateless pages? Possibly using a custom PageMap implementation? Although newer JVM's are good at performing GC, pooling is a reasonable additional technique to use for achieving that extra bit of scalability. If anyone has tried to do this, or has any suggestions on the best way forward I'd be really interested to know. Many Thanks, Joel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page pooling (for stateless pages)
For stateless pages?? The whole point of stateless is that they arent kept in the session/memory. And pooling pages is not really what you want any way, you can only pool then for a single user/sessiion so you would have a pool for every session. And when do you decide to return a pooled page? On 5/18/08, Joel Halbert [EMAIL PROTECTED] wrote: Hi, I was wondering whether it was possible to implement pooling of stateless pages? Possibly using a custom PageMap implementation? Although newer JVM's are good at performing GC, pooling is a reasonable additional technique to use for achieving that extra bit of scalability. If anyone has tried to do this, or has any suggestions on the best way forward I'd be really interested to know. Many Thanks, Joel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page pooling (for stateless pages)
For stateless pages?? The whole point of stateless is that they arent kept in the session/memory. And pooling pages is not really what you want any way, you can only pool then for a single user/sessiion so you would have a pool for every session. And when do you decide to return a pooled page? On 5/18/08, Joel Halbert [EMAIL PROTECTED] wrote: Hi, I was wondering whether it was possible to implement pooling of stateless pages? Possibly using a custom PageMap implementation? Although newer JVM's are good at performing GC, pooling is a reasonable additional technique to use for achieving that extra bit of scalability. If anyone has tried to do this, or has any suggestions on the best way forward I'd be really interested to know. Many Thanks, Joel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page pooling (for stateless pages)
Johan, Although the pages are stateless, they can still be pooled, and re-initialised (their state cleared out) between requests. This is indeed what many java servlet containers do with stateless Servlets. It is also the a technique used by Tapestry 5 to achieve greater scalability. Rgs, Joel -- From: Johan Compagner [EMAIL PROTECTED] Sent: Sunday, May 18, 2008 12:27 PM To: users@wicket.apache.org Subject: Re: Page pooling (for stateless pages) For stateless pages?? The whole point of stateless is that they arent kept in the session/memory. And pooling pages is not really what you want any way, you can only pool then for a single user/sessiion so you would have a pool for every session. And when do you decide to return a pooled page? On 5/18/08, Joel Halbert [EMAIL PROTECTED] wrote: Hi, I was wondering whether it was possible to implement pooling of stateless pages? Possibly using a custom PageMap implementation? Although newer JVM's are good at performing GC, pooling is a reasonable additional technique to use for achieving that extra bit of scalability. If anyone has tried to do this, or has any suggestions on the best way forward I'd be really interested to know. Many Thanks, Joel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page pooling (for stateless pages)
The overhead incurred would of course depend on the number or requests the app was receiving, the amount of available memory and the efficiency of the chosen GC algorithm. I agree that object creation and collection is relatively efficient these days, but pooling still makes sense where it can be implemented. I noted that Tapestry 5 has chosen to implement stateless pages and pooling of these by default. -- From: Matej Knopp [EMAIL PROTECTED] Sent: Sunday, May 18, 2008 12:25 PM To: users@wicket.apache.org Subject: Re: Page pooling (for stateless pages) Hi, first of all, I don't really think it's worth pooling pages. I can't imagine that page instance creation would have that much overhead. Also stateless pages doesn't mean they don't contain any state. The page is stateless because it's not kept between requests, but during request there's lot going on with the page. So you can't just reuse the instances. -Matej On Sun, May 18, 2008 at 1:10 PM, Joel Halbert [EMAIL PROTECTED] wrote: Hi, I was wondering whether it was possible to implement pooling of stateless pages? Possibly using a custom PageMap implementation? Although newer JVM's are good at performing GC, pooling is a reasonable additional technique to use for achieving that extra bit of scalability. If anyone has tried to do this, or has any suggestions on the best way forward I'd be really interested to know. Many Thanks, Joel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page pooling (for stateless pages)
We are not tapestry 5. :D Seriously: page pooling is not good for scalabity. You need to apply locks to prevent multiple threads to access the same instance, etc. There is a whole lot of additional stuff you need to make this work, adding complexity for little or quite possibly no gain at all. Martijn On 5/18/08, Joel Halbert [EMAIL PROTECTED] wrote: Johan, Although the pages are stateless, they can still be pooled, and re-initialised (their state cleared out) between requests. This is indeed what many java servlet containers do with stateless Servlets. It is also the a technique used by Tapestry 5 to achieve greater scalability. Rgs, Joel -- From: Johan Compagner [EMAIL PROTECTED] Sent: Sunday, May 18, 2008 12:27 PM To: users@wicket.apache.org Subject: Re: Page pooling (for stateless pages) For stateless pages?? The whole point of stateless is that they arent kept in the session/memory. And pooling pages is not really what you want any way, you can only pool then for a single user/sessiion so you would have a pool for every session. And when do you decide to return a pooled page? On 5/18/08, Joel Halbert [EMAIL PROTECTED] wrote: Hi, I was wondering whether it was possible to implement pooling of stateless pages? Possibly using a custom PageMap implementation? Although newer JVM's are good at performing GC, pooling is a reasonable additional technique to use for achieving that extra bit of scalability. If anyone has tried to do this, or has any suggestions on the best way forward I'd be really interested to know. Many Thanks, Joel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page pooling (for stateless pages)
I would agree it's not always going to give much mileage. Given that there is no heavy weight initialization going on with pages I would tend to agree. The JVM should be able to cope with many 10's of thousands of objects created destroyed per sec, more or less system dependent, so long as they are all young gen objects. And with parallel gc this should result in minimal effect on an application. -- From: Martijn Dashorst [EMAIL PROTECTED] Sent: Sunday, May 18, 2008 12:42 PM To: users@wicket.apache.org Subject: Re: Page pooling (for stateless pages) We are not tapestry 5. :D Seriously: page pooling is not good for scalabity. You need to apply locks to prevent multiple threads to access the same instance, etc. There is a whole lot of additional stuff you need to make this work, adding complexity for little or quite possibly no gain at all. Martijn On 5/18/08, Joel Halbert [EMAIL PROTECTED] wrote: Johan, Although the pages are stateless, they can still be pooled, and re-initialised (their state cleared out) between requests. This is indeed what many java servlet containers do with stateless Servlets. It is also the a technique used by Tapestry 5 to achieve greater scalability. Rgs, Joel -- From: Johan Compagner [EMAIL PROTECTED] Sent: Sunday, May 18, 2008 12:27 PM To: users@wicket.apache.org Subject: Re: Page pooling (for stateless pages) For stateless pages?? The whole point of stateless is that they arent kept in the session/memory. And pooling pages is not really what you want any way, you can only pool then for a single user/sessiion so you would have a pool for every session. And when do you decide to return a pooled page? On 5/18/08, Joel Halbert [EMAIL PROTECTED] wrote: Hi, I was wondering whether it was possible to implement pooling of stateless pages? Possibly using a custom PageMap implementation? Although newer JVM's are good at performing GC, pooling is a reasonable additional technique to use for achieving that extra bit of scalability. If anyone has tried to do this, or has any suggestions on the best way forward I'd be really interested to know. Many Thanks, Joel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page pooling (for stateless pages)
I agree with Johan. Stateless in Wicket sense means that we don't keep the page in memory but recreate it from scratch. This means that we don't roll back state. Pooling requires us (the framework or the users) to rollback any state that was accumulated during rendering. This is really not an avenue I want to pursue. Martijn On 5/18/08, Joel Halbert [EMAIL PROTECTED] wrote: Johan, Although the pages are stateless, they can still be pooled, and re-initialised (their state cleared out) between requests. This is indeed what many java servlet containers do with stateless Servlets. It is also the a technique used by Tapestry 5 to achieve greater scalability. Rgs, Joel -- From: Johan Compagner [EMAIL PROTECTED] Sent: Sunday, May 18, 2008 12:27 PM To: users@wicket.apache.org Subject: Re: Page pooling (for stateless pages) For stateless pages?? The whole point of stateless is that they arent kept in the session/memory. And pooling pages is not really what you want any way, you can only pool then for a single user/sessiion so you would have a pool for every session. And when do you decide to return a pooled page? On 5/18/08, Joel Halbert [EMAIL PROTECTED] wrote: Hi, I was wondering whether it was possible to implement pooling of stateless pages? Possibly using a custom PageMap implementation? Although newer JVM's are good at performing GC, pooling is a reasonable additional technique to use for achieving that extra bit of scalability. If anyone has tried to do this, or has any suggestions on the best way forward I'd be really interested to know. Many Thanks, Joel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page pooling (for stateless pages)
If you were to add in pooling, you'd have to either provide a new hook (new lifecycle method) or a warning to the user (as you mentioned) that they have to rollback the state themselves after rendering using onAfterRender() or something. On Sun, May 18, 2008 at 8:23 AM, Martijn Dashorst [EMAIL PROTECTED] wrote: I agree with Johan. Stateless in Wicket sense means that we don't keep the page in memory but recreate it from scratch. This means that we don't roll back state. Pooling requires us (the framework or the users) to rollback any state that was accumulated during rendering. This is really not an avenue I want to pursue. Martijn On 5/18/08, Joel Halbert [EMAIL PROTECTED] wrote: Johan, Although the pages are stateless, they can still be pooled, and re-initialised (their state cleared out) between requests. This is indeed what many java servlet containers do with stateless Servlets. It is also the a technique used by Tapestry 5 to achieve greater scalability. Rgs, Joel -- From: Johan Compagner [EMAIL PROTECTED] Sent: Sunday, May 18, 2008 12:27 PM To: users@wicket.apache.org Subject: Re: Page pooling (for stateless pages) For stateless pages?? The whole point of stateless is that they arent kept in the session/memory. And pooling pages is not really what you want any way, you can only pool then for a single user/sessiion so you would have a pool for every session. And when do you decide to return a pooled page? On 5/18/08, Joel Halbert [EMAIL PROTECTED] wrote: Hi, I was wondering whether it was possible to implement pooling of stateless pages? Possibly using a custom PageMap implementation? Although newer JVM's are good at performing GC, pooling is a reasonable additional technique to use for achieving that extra bit of scalability. If anyone has tried to do this, or has any suggestions on the best way forward I'd be really interested to know. Many Thanks, Joel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page pooling (for stateless pages)
do you have a benchmark that shows that pooling is indeed faster? servlets are pooled because they may require heavy initialization. wicket pages are much more lightweight in comparison. -igor On Sun, May 18, 2008 at 4:36 AM, Joel Halbert [EMAIL PROTECTED] wrote: Johan, Although the pages are stateless, they can still be pooled, and re-initialised (their state cleared out) between requests. This is indeed what many java servlet containers do with stateless Servlets. It is also the a technique used by Tapestry 5 to achieve greater scalability. Rgs, Joel -- From: Johan Compagner [EMAIL PROTECTED] Sent: Sunday, May 18, 2008 12:27 PM To: users@wicket.apache.org Subject: Re: Page pooling (for stateless pages) For stateless pages?? The whole point of stateless is that they arent kept in the session/memory. And pooling pages is not really what you want any way, you can only pool then for a single user/sessiion so you would have a pool for every session. And when do you decide to return a pooled page? On 5/18/08, Joel Halbert [EMAIL PROTECTED] wrote: Hi, I was wondering whether it was possible to implement pooling of stateless pages? Possibly using a custom PageMap implementation? Although newer JVM's are good at performing GC, pooling is a reasonable additional technique to use for achieving that extra bit of scalability. If anyone has tried to do this, or has any suggestions on the best way forward I'd be really interested to know. Many Thanks, Joel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page pooling (for stateless pages)
On Sun, May 18, 2008 at 9:47 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: do you have a benchmark that shows that pooling is indeed faster? servlets are pooled because they may require heavy initialization. wicket pages are much more lightweight in comparison. And, the more heavyweight you make your page, the more likely that it isn't stateless anymore anyway. :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page pooling (for stateless pages)
I was wondering whether it was possible to implement pooling of stateless pages? Possibly using a custom PageMap implementation? I think you can just implement the pooling mechanism yourself, and provide a custom version of IPageFactory (which is to be set in session settings). Although newer JVM's are good at performing GC, pooling is a reasonable additional technique to use for achieving that extra bit of scalability. Like other team members, I doubt this :-) Like any advantages you might have will be lost by the need to synchronize. And if your page is really heavy to construct, that is probably a sign that you should move your 'heavy code' (probably database access?) to the rendering phase (like using lazy initialized models and algorithms for components such as overriding isVisible rather than setting it). But nothing beats real numbers, and it may be worth it for your case. Let us know if it made a difference for you. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page pooling (for stateless pages)
Yes. That's what I would do. Build your application (or better yet build a quick prototype to test your scalability) simply and then profile it. If there are any hotspots, look at them then. Ayodeji Aladejebi wrote: Why do ppl really like doing extra work trying to help Wicket? For me, short of making proper use of Models and Bookmarkable Pages and buying extra hardware where possible, I dont really crack my head too much on certain things. I kind of trust the highly skillful wicket team to do their job when it comes to evolving a high performant framework. just my thots On 5/18/08, Joel Halbert [EMAIL PROTECTED] wrote: Thanks all for the feedback. Given that there is no heavy initialisation going on in any of our pages I would tend to agree that page construction, should be fairly cheap, and would certainly be cheaper than any constant contended synchronisation. I however keep an eye on it and let you know of any metrics that we produce. Thx, Joel -- From: Eelco Hillenius [EMAIL PROTECTED] Sent: Sunday, May 18, 2008 5:58 PM To: users@wicket.apache.org Subject: Re: Page pooling (for stateless pages) I was wondering whether it was possible to implement pooling of stateless pages? Possibly using a custom PageMap implementation? I think you can just implement the pooling mechanism yourself, and provide a custom version of IPageFactory (which is to be set in session settings). Although newer JVM's are good at performing GC, pooling is a reasonable additional technique to use for achieving that extra bit of scalability. Like other team members, I doubt this :-) Like any advantages you might have will be lost by the need to synchronize. And if your page is really heavy to construct, that is probably a sign that you should move your 'heavy code' (probably database access?) to the rendering phase (like using lazy initialized models and algorithms for components such as overriding isVisible rather than setting it). But nothing beats real numbers, and it may be worth it for your case. Let us know if it made a difference for you. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Page-pooling-%28for-stateless-pages%29-tp17301659p17307591.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]
Re: Page pooling (for stateless pages)
Hello, I think it would probably make more sense to cache the /result/ of stateless pages. Regards, Erik. Joel Halbert wrote: Hi, I was wondering whether it was possible to implement pooling of stateless pages? Possibly using a custom PageMap implementation? Although newer JVM's are good at performing GC, pooling is a reasonable additional technique to use for achieving that extra bit of scalability. If anyone has tried to do this, or has any suggestions on the best way forward I'd be really interested to know. Many Thanks, Joel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page pooling (for stateless pages)
I think it would probably make more sense to cache the /result/ of stateless pages. Yeah, that might make quite the difference. The best place for that would be a filter, probably defined before the Wicket filter. Tons of different options as well though. And definitively something I would only investigate if I was either experience scaling problems or would have a scale that I would know upfront it might save a bunch of servers. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
