Re: Fwd: How to reduce Memory Footprint
On Tue, 03 Mar 2015 09:36:11 -0300, Robert Schmelzer wrote: Hi, Hi! we built a prototype based on your suggestions. The main idea would work - but there is one main issue we are not able to address: Event propagation - if the component fires a request it will be propagated to its "dummy" page where the component is hosted and we cannot attach listeneres on it. Actually, there is. Take a look at how the Form component and the form field components (TextField, etc) work. They use the Environment to pass Form information about events to be triggered when the form is submitted. This also avoid the use of @Persist. So it seems that we have to take a closer look on where to buy cheap RAM ;-). Not yet. ;) -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Fwd: How to reduce Memory Footprint
Hi, we built a prototype based on your suggestions. The main idea would work - but there is one main issue we are not able to address: Event propagation - if the component fires a request it will be propagated to its "dummy" page where the component is hosted and we cannot attach listeneres on it. Another thing was, that the former parameters must be changed to @Persist because in sub-sequent requests to the dialog the Environment will not be filled. So we grow up the session, which is also not ideal. So it seems that we have to take a closer look on where to buy cheap RAM ;-). Robert Am 02.03.2015 um 16:24 schrieb Thiago H de Paula Figueiredo: On Mon, 02 Mar 2015 11:42:57 -0300, Robert Schmelzer wrote: Thanks for the immediate response. ;) We are building a product which acts as a complete backoffice solution for a specific business type - so yes the 220 pages are doing really different things. Wow indeed. :) The reusable parts are all modeled as components. And yes your assumption is right, all of the pages have an huge number of embedded components. I already thougth about this type of "block contributions" but I fear it a bit, because the usage gets so much more complicated. So I like the idea to encapsulate that aspect in its own component. Thanks for that. Yeah, you'll need to write a second component, but then you won't need to change the existing usages of your component at all. It diminishes the cost of change a lot. We will try to make a prototype for it. But as I feared - the answer is not simple - we will have to rebuild 100+ dialogs if we really want to save the RAM spendings... You can try figuring out the worst offender (the larger ones) and work on them first. Cheers Robert Am 02.03.2015 um 15:33 schrieb Thiago H de Paula Figueiredo: On Mon, 02 Mar 2015 10:43:09 -0300, Robert Schmelzer wrote: Hi, Hi! we have a quite big business app counting about 220 pages. Wow! 220! Does it really need that many unique pages? Does each one have its own logic, different from the others? By the way, which Tapestry version does the application use? We are using a UX style where you can pop up dialogs containing wizards, which can again pop up dialogs and so on. The dialogs are opened in AJAX request on top of the page and realized in tapestry as embedded components. This shouldn't be a problem not impact the memory usage directly, unless you have one or more pages or components with a large number of embedded components and just a few of them used per request. If this is actually the case, and it may be, please let us know so we can present an approach to deal with this. With this structure we are ending up, having four ComponentPageElementImpl instances for Dialog D . In our very deeply stacked and multiple times reused scenario we are ending up having about 200 000 ComponentPageElementImpl instances. For example we have a single page holding 23 000 ComponentPageElementImpl instances. That's definitely a problem, probably proving that assumption in my paragraph above is true. How can we adress this problem? Does anyone have an idea, how we can reuse such dialogs, without duplicating them in the memory? The approach is doing something similar to what BeanEditor, Grid et al. use: create a DialogDPage page (name doesn't matter). In its template, create a render it, use the Delegate component. * If you're going to use this component in many pages, you can rename DialogD to InternalDialogD and create a DialogD component that receives parameters the usual way (@Parameter fields) and deals with the Environment and ComponentSource by itself. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Fwd: How to reduce Memory Footprint
On Mon, 02 Mar 2015 11:42:57 -0300, Robert Schmelzer wrote: Thanks for the immediate response. ;) We are building a product which acts as a complete backoffice solution for a specific business type - so yes the 220 pages are doing really different things. Wow indeed. :) The reusable parts are all modeled as components. And yes your assumption is right, all of the pages have an huge number of embedded components. I already thougth about this type of "block contributions" but I fear it a bit, because the usage gets so much more complicated. So I like the idea to encapsulate that aspect in its own component. Thanks for that. Yeah, you'll need to write a second component, but then you won't need to change the existing usages of your component at all. It diminishes the cost of change a lot. We will try to make a prototype for it. But as I feared - the answer is not simple - we will have to rebuild 100+ dialogs if we really want to save the RAM spendings... You can try figuring out the worst offender (the larger ones) and work on them first. Cheers Robert Am 02.03.2015 um 15:33 schrieb Thiago H de Paula Figueiredo: On Mon, 02 Mar 2015 10:43:09 -0300, Robert Schmelzer wrote: Hi, Hi! we have a quite big business app counting about 220 pages. Wow! 220! Does it really need that many unique pages? Does each one have its own logic, different from the others? By the way, which Tapestry version does the application use? We are using a UX style where you can pop up dialogs containing wizards, which can again pop up dialogs and so on. The dialogs are opened in AJAX request on top of the page and realized in tapestry as embedded components. This shouldn't be a problem not impact the memory usage directly, unless you have one or more pages or components with a large number of embedded components and just a few of them used per request. If this is actually the case, and it may be, please let us know so we can present an approach to deal with this. With this structure we are ending up, having four ComponentPageElementImpl instances for Dialog D . In our very deeply stacked and multiple times reused scenario we are ending up having about 200 000 ComponentPageElementImpl instances. For example we have a single page holding 23 000 ComponentPageElementImpl instances. That's definitely a problem, probably proving that assumption in my paragraph above is true. How can we adress this problem? Does anyone have an idea, how we can reuse such dialogs, without duplicating them in the memory? The approach is doing something similar to what BeanEditor, Grid et al. use: create a DialogDPage page (name doesn't matter). In its template, create a it, use the Delegate component. * If you're going to use this component in many pages, you can rename DialogD to InternalDialogD and create a DialogD component that receives parameters the usual way (@Parameter fields) and deals with the Environment and ComponentSource by itself. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
How to reduce Memory Footprint
Hi, we have a quite big business app counting about 220 pages. We are using a UX style where you can pop up dialogs containing wizards, which can again pop up dialogs and so on. The dialogs are opened in AJAX request on top of the page and realized in tapestry as embedded components. After full initialization of the app, the tapestry caches take about 800MB of Old Generation Heap Space in the JVM. Overall we need about 1.2 GB so Tapestry consumes about 75% of our Old Generation heap. So we end-up with a structure like this: Page 1 -> Wizard A -> Dialog B -> Wizard C -> Dialog D Wizard D -> Dialog D Page 2 -> Wizard A -> Dialog B -> Wizard C -> Dialog D Wizard D -> Dialog D With this structure we are ending up, having four ComponentPageElementImpl instances for Dialog D . In our very deeply stacked and multiple times reused scenario we are ending up having about 200 000 ComponentPageElementImpl instances. For example we have a single page holding 23 000 ComponentPageElementImpl instances. How can we adress this problem? Does anyone have an idea, how we can reuse such dialogs, without duplicating them in the memory? THX Robert Schmelzer - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Fwd: How to reduce Memory Footprint
Thanks for the immediate response. We are building a product which acts as a complete backoffice solution for a specific business type - so yes the 220 pages are doing really different things. The reusable parts are all modeled as components. And yes your assumption is right, all of the pages have an huge number of embedded components. I already thougth about this type of "block contributions" but I fear it a bit, because the usage gets so much more complicated. So I like the idea to encapsulate that aspect in its own component. Thanks for that. We will try to make a prototype for it. But as I feared - the answer is not simple - we will have to rebuild 100+ dialogs if we really want to save the RAM spendings... Cheers Robert Am 02.03.2015 um 15:33 schrieb Thiago H de Paula Figueiredo: On Mon, 02 Mar 2015 10:43:09 -0300, Robert Schmelzer wrote: Hi, Hi! we have a quite big business app counting about 220 pages. Wow! 220! Does it really need that many unique pages? Does each one have its own logic, different from the others? By the way, which Tapestry version does the application use? We are using a UX style where you can pop up dialogs containing wizards, which can again pop up dialogs and so on. The dialogs are opened in AJAX request on top of the page and realized in tapestry as embedded components. This shouldn't be a problem not impact the memory usage directly, unless you have one or more pages or components with a large number of embedded components and just a few of them used per request. If this is actually the case, and it may be, please let us know so we can present an approach to deal with this. With this structure we are ending up, having four ComponentPageElementImpl instances for Dialog D . In our very deeply stacked and multiple times reused scenario we are ending up having about 200 000 ComponentPageElementImpl instances. For example we have a single page holding 23 000 ComponentPageElementImpl instances. That's definitely a problem, probably proving that assumption in my paragraph above is true. How can we adress this problem? Does anyone have an idea, how we can reuse such dialogs, without duplicating them in the memory? The approach is doing something similar to what BeanEditor, Grid et al. use: create a DialogDPage page (name doesn't matter). In its template, create a it, use the Delegate component. * If you're going to use this component in many pages, you can rename DialogD to InternalDialogD and create a DialogD component that receives parameters the usual way (@Parameter fields) and deals with the Environment and ComponentSource by itself. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Fwd: How to reduce Memory Footprint
On Mon, 02 Mar 2015 10:43:09 -0300, Robert Schmelzer wrote: Hi, Hi! we have a quite big business app counting about 220 pages. Wow! 220! Does it really need that many unique pages? Does each one have its own logic, different from the others? By the way, which Tapestry version does the application use? We are using a UX style where you can pop up dialogs containing wizards, which can again pop up dialogs and so on. The dialogs are opened in AJAX request on top of the page and realized in tapestry as embedded components. This shouldn't be a problem not impact the memory usage directly, unless you have one or more pages or components with a large number of embedded components and just a few of them used per request. If this is actually the case, and it may be, please let us know so we can present an approach to deal with this. With this structure we are ending up, having four ComponentPageElementImpl instances for Dialog D . In our very deeply stacked and multiple times reused scenario we are ending up having about 200 000 ComponentPageElementImpl instances. For example we have a single page holding 23 000 ComponentPageElementImpl instances. That's definitely a problem, probably proving that assumption in my paragraph above is true. How can we adress this problem? Does anyone have an idea, how we can reuse such dialogs, without duplicating them in the memory? The approach is doing something similar to what BeanEditor, Grid et al. use: create a DialogDPage page (name doesn't matter). In its template, create a use the Delegate component. * If you're going to use this component in many pages, you can rename DialogD to InternalDialogD and create a DialogD component that receives parameters the usual way (@Parameter fields) and deals with the Environment and ComponentSource by itself. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Fwd: How to reduce Memory Footprint
Hi, we have a quite big business app counting about 220 pages. We are using a UX style where you can pop up dialogs containing wizards, which can again pop up dialogs and so on. The dialogs are opened in AJAX request on top of the page and realized in tapestry as embedded components. After full initialization of the app, the tapestry caches take about 800MB of Old Generation Heap Space in the JVM. Overall we need about 1.2 GB so Tapestry consumes about 75% of our Old Generation heap. So we end-up with a structure like this: Page 1 -> Wizard A -> Dialog B -> Wizard C -> Dialog D Wizard D -> Dialog D Page 2 -> Wizard A -> Dialog B -> Wizard C -> Dialog D Wizard D -> Dialog D With this structure we are ending up, having four ComponentPageElementImpl instances for Dialog D . In our very deeply stacked and multiple times reused scenario we are ending up having about 200 000 ComponentPageElementImpl instances. For example we have a single page holding 23 000 ComponentPageElementImpl instances. How can we adress this problem? Does anyone have an idea, how we can reuse such dialogs, without duplicating them in the memory? THX Robert Schmelzer - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
