Eclipse Community Forums: Remote Application Platform (RAP) » Reducing RAP memory consumption (serverside / per session)

Home » Eclipse Projects » Remote Application Platform (RAP) » Reducing RAP memory consumption (serverside / per session)

Show: Today's Messages :: Show Polls :: Message Navigator

Reducing RAP memory consumption (serverside / per session) [message #96916]

Fri, 04 July 2008 16:57

Stefan Hansel

Messages: 103
Registered: July 2009

Senior Member

Are there any ideas or plans to tune
RAP memory consumption for each RAP-session ?
 
 I did some tests with a simple GUI (1x
Shell, 50 Labels, 50 Textareas, 1 Button) with a RAP-Standalone-Webapp
(no Workbench, no equinox used).
 The result are not too amazing - 2000
concurrent users/session swallow aprrox. 750MB of Heap in this simple scenario
(*shiver*).
 
 When analyzing the HEAP it turns out,
that (as expected) most of the widgets (in this case Label-texts) take
that memory.
 
 Following ideas came into my mind:
 
 1) Most of the stateful data could be
put into the session itself. Thus a servlet-container could serialize the
session and have some more headroom left when more users come into play.
 On the long run, this would just be
just a little improvement in my opinion.
 
 
 2) I'm aware that RAP is very stateful
- but in 99% of the time Label-texts are only set, never read.
 So when the request is answered to the
browser all label-texts could be nulled, because qooxdoo then shows the
labels and would only be interested in textchanges (which could only be
triggered by a new 'setText').
 
 Looking at the code of a label the text
(if not requested by the getter) is only used for size-calculations (which
eventually take place in later requests due to relayouting). But just calculating
and caching the size when the text is set would be far more memory friendly
then saving the Label-text all the time.
 
 Of course - to be fully backward-compatible
such a memory-saving mode had to be optional (in the worst case to be specified
for each label). There might be some cases, when an application wants to
read its own Label-texts.
 
 A similar optimization could be done
with TableItemDatas I assume. Actually the application holds the TableModel
in memory so there is no need to keep all the texts of each cell in memory.
 
 
 What do you think ? Do those optimizations
sound reasonable to you, would it make sense to dig deeper into this ?
At least for me it sounds as if up to 50% of the session-state could be
eliminated this way.
 Or do you expect problems because Label-texts
are read more (in later requests) than I might think ?
 Are there other ideas to face the problem
?
 
 How do other people work around the
memory issue ? I'm pretty amazed that RAP-applications are run on the internet
(Yoxos, RAP-Demos) instead of just intranets, where the user-count is limited
?

Report message to a moderator

Re: Reducing RAP memory consumption (serverside / per session) [message #97115 is a reply to message #96916]

Sun, 06 July 2008 21:15

Stefan Hansel

Messages: 103
Registered: July 2009

Senior Member

Ooops. 
 I'm very sorry but just realized, that
I posted wrong statistics.
 
 Corrected: Tests where done with a composite
containing 200 Label- + 200 (empty) Text-Widgets * 2000 sessions. (not
50Labels/Texts as stated in the previous post).
 The heap grows up to 740MB (measured
by just dumping the heap).
 
 Anyway - I did some further heap investigations
and I have to correct my suggestions a bit: 
 If Labels-texts are not generated, then
they are not consuming that much heap, because the same String is referenced
by all sessions.
 
 I found 2 other memory consumers instead:
 WidgetAdapter (which holds a 'preservedValue'-HashMap
which seems to be only needed while processing requests, but not for 'idle'-sessions)
 EventAdapter (which is actually written
to save memory in its 'listenerSets' - but since every Widget gets at least
a DisposeListener, it needs memory for every widget though).
 
 When optimizing this (can provide patches
later after some more testing) I was able to drop memory-consumption of
the same app to 450MB for 2000 open sessions.
 
 Still leaves the question, if you think

 1) that TableItem$Data's could be cleared
after rendering if an app doesn't need read-access on them (which helped
apps which are quite stateless and keep only refrences to object-ids after
creating a table)
 2) that Label.text could be cleared
after rendering if an app doesn't need read-access on them (which helped
apps with generated labels)

Report message to a moderator

Re: Reducing RAP memory consumption (serverside / per session) [message #97278 is a reply to message #97115]

Tue, 08 July 2008 10:42

Eclipse User

Originally posted by: rherrmann.innoopract.com

Hi Stefan,

thanks for your input. As a general note, RAP aims to bring the -
what we believe powerful - Eclipse programming model to the web.
Thus it is server-centric and stateful with all its pros and cons.

Please also see my comments below.

Cheers,
Rüdiger

stefan.hansel@tolina.de wrote:
>
> Ooops.
> I'm very sorry but just realized, that I posted wrong statistics.
>
> Corrected: Tests where done with a composite containing 200 Label- + 200
> (empty) Text-Widgets * 2000 sessions. (not 50Labels/Texts as stated in
> the previous post).
> The heap grows up to 740MB (measured by just dumping the heap).
Could you provide more details on what methods and tools these
numbers are based?

From your numbers, it is not clear what increase in memory the 2000
sessions caused. Under the assumption that the entire 740MB are
consumed by the 2000 sessions, this would result in 0.37MB per session.

>
> Anyway - I did some further heap investigations and I have to correct my
> suggestions a bit:
> If Labels-texts are not generated, then they are not consuming that much
> heap, because the same String is referenced by all sessions.
I think, generated label texts are closes to a real-world scenario.
An application would probably read strings from a localized
properties file or similar and thus consume more memory that the
interned literal or constant strings.

>
> I found 2 other memory consumers instead:
> WidgetAdapter (which holds a 'preservedValue'-HashMap which seems to be
> only needed while processing requests, but not for 'idle'-sessions)
After processing a request, the preservedValues map is cleared with
Map#clear(). This could be changed to discard of the map
(preservedValues = null) if it is proven that the there is a
considerable benefit in memory consumption. On the other hand, this
might have a performance impact when re-creating the map and all its
entries with every request.

> EventAdapter (which is actually written to save memory in its
> 'listenerSets' - but since every Widget gets at least a DisposeListener,
> it needs memory for every widget though).
Just to clarify, the EventAdapter wasn't written to save memory.
Only the ListenerSet, which does not allocate more memory than
necessary to hold all elements.

>
> When optimizing this (can provide patches later after some more testing)
> I was able to drop memory-consumption of the same app to 450MB for 2000
> open sessions.
You are welcome. Please file a bug to attach the patches to.

>
> Still leaves the question, if you think
> 1) that TableItem$Data's could be cleared after rendering if an app
> doesn't need read-access on them (which helped apps which are quite
> stateless and keep only refrences to object-ids after creating a table)
> 2) that Label.text could be cleared after rendering if an app doesn't
> need read-access on them (which helped apps with generated labels)
From a technical point of view, apart from very rare cases I don't
see a chance to partly discard a widgets state.
Depending on the parents layout, a widgets text is needed for
re-layouting (e.g. after one of its parents was resized) and for
text size requests.
Moreover from my point of view, programming against such
half-stateful widgets would be very error-prone. The programmer
would have to keep things in mind (e.g. are we serving the first
request?) that aren't obvious from reading the code. The widget
would reveal implementation details to its clients.

Report message to a moderator

Re: Reducing RAP memory consumption (serverside / per session) [message #97325 is a reply to message #97278]

Tue, 08 July 2008 17:55

Stefan Hansel

Messages: 103
Registered: July 2009

Senior Member

<tt>Hi Rüdiger, </tt>
 
 <tt>>> Thus it is server-centric and stateful with
all its pros and cons.</tt>
 <tt>Nevertheless can be tuned a lot, under some conditions
which should not be too difficult to adhere to (I hope) ;-)</tt>
 
 <tt>>> From your numbers, it is not clear what increase
in memory the 2000 
>> sessions caused. Under the assumption that the entire 740MB are
 
>> consumed by the 2000 sessions, this would result in 0.37MB per
session.</tt>
 
 <tt>Indeed - quite a lot :D, but nevertheless your guess
is true.</tt>
 <tt>Here you'll have an export from SAP-Memory-Analyzer.
(For a definition of 'retained Heap' see </tt><a href=http://jazoon.com/download/presentations/2160.pdf><tt>http://jazoon.com/download/presentations/2160.pdf</tt></a><tt>
, slide 18)</tt>
 <tt>As you can see 400.000 Text's and Label's (200 * 2000
sessions) take up most of the HEAP (60%).</tt>
 <tt>Another big consumer in my example is the use of JGoodies-(SWT-ported)-FormLayout
(using and tuning this is our problem - don't know how much a GridLayout
would take) all other controls don't make up that big percentage of the
heap.</tt>
 
 <tt>Class Name            
                     
       | Objects | Shallow Heap | Retained Heap | Retained
Heap, % </tt>
 <tt> ------------------------------------------------------------ -------------------------------------------------- </tt>
 <tt><ROOT>            
                     
           |       1 |  
         0 |          
    |                
 </tt>
 <tt>|- org.eclipse.swt.widgets.Composite    
           |   4.000 |    
 448.000 |   705.792.016 |          
95,44% </tt>
 <tt>|  |- org.eclipse.swt.widgets.Text    
             | 400.000 |   41.600.000
|   246.400.000 |           33,32% </tt>
 <tt>|  |- org.eclipse.swt.widgets.Label    
            | 406.000 |   38.976.000
|   240.272.016 |           32,49% </tt>
 <tt>|  |- net.ffxml.swtforms.layout.FormLayout  
       |   4.000 |      256.000
|   207.728.000 |           28,09% </tt>
 <tt>|  |- org.eclipse.swt.widgets.Composite  
          |   2.000 |      224000
|     4.256.000 |            0,58%
</tt>
 <tt>|  |- org.eclipse.swt.widgets.ControlHolder  
      |   4.000 |       64.000 |  
  3.472.000 |            0,47% </tt>
 <tt>|  |- org.eclipse.swt.widgets.Button    
           |   2.000 |    
 208.000 |     1.248.000 |          
 0,17% </tt>
 <tt>|  |- org.eclipse.swt.internal.widgets.WidgetAdapter|
  4.000 |      128.000 |     1.040.000 |
           0,14% </tt>
 <tt>|  |- org.eclipse.rwt.internal.events.EventAdapter
 |   4.000 |       64.000 |      
768.000 |            0,10% </tt>
 <tt>|  |- org.eclipse.swt.graphics.Rectangle  
         |   4.000 |      
96.000 |        96.000 |        
   0,01% </tt>
 <tt>|  '- org.eclipse.swt.widgets.Control$ControlAdapter|
  4.000 |       64.000 |        64.000
|            0,01% </tt>
 <tt> ------------------------------------------------------------ -------------------------------------------------- </tt>
 
 <tt>If you drill down further (e.g. Text), you see that
WidgetAdapter and EventAdapter take a lot of space for their </tt>
 <tt>empty (quite-empty for EventAdapter) HashMaps (140MB
- double this, because all Label's take the same size again).</tt>
 <tt>If you consider that most of the widgets will never
need an Eventlistener this is quite a lot.</tt>
 
 <tt>Class Name            
                     
          | Objects | Shallow Heap | Retained
Heap | Retained Heap, % </tt>
 <tt> ------------------------------------------------------------ ----------------------------------------------------- </tt>
 <tt><ROOT>            
                     
              |      
1 |            0 |        
      |              
   </tt>
 <tt>|- org.eclipse.swt.widgets.Composite    
              |   4.000 |  
   448.000 |   705.792.016 |        
  95,44% </tt>
 <tt>|  |- org.eclipse.swt.widgets.Text    
                | 400.000 |  
41.600.000 |   246.400.000 |           33,32%
</tt>
 <tt>|  |  |- org.eclipse.swt.internal.widgets.WidgetAdapter|
400.000 |   12.800.000 |   105.600.000 |      
    14,28% </tt>
 <tt>|  |  |  |- java.util.HashMap  
                     
 | 400.000 |   16.000.000 |    73.600.000 |  
         9,95% </tt>
 <tt>|  |  |  '- java.lang.String  
                     
  | 400.000 |    9.600.000 |    19.200.000 |  
         2,60% </tt>
 <tt>|  |  |- org.eclipse.rwt.internal.events.EventAdapter
 | 400.000 |    6.400.000 |    76.800.000 |  
        10,39% </tt>
 <tt>|  |  |  '- java.util.HashMap  
                     
 | 400.000 |   16.000.000 |    70.400.000 |  
         9,52% </tt>
 <tt> ------------------------------------------------------------ ----------------------------------------------------- </tt>
 
 <tt>Note that in this example Label-Strings don't count
as Retained Heap for the Label, 'cause the strings are shared by all Label's.</tt>
 <tt>The String's you see in the stats above are the widgetIDs
held be the WidgetAdapter. These could be tuned as well (saved as a Long
as long as no custom widget-IDs are used). I'll provide a patch for that
too.</tt>
 
 <tt>>> On the other hand, this might have a performance
impact when re-creating the map and all its entries with every request.</tt>
 <tt>Not too much I suppose. Object Creation is really
fast with current VMs - 'ten machine instructions' for java 1.4 and 1.5
according to guru Brian Goetz in 'Java Concurrency In Practice' (p. 241).</tt>
 
 <tt>>> I think, generated label texts are closes
to a real-world scenario. </tt>
 <tt>So tuning would have a big benefit. As I said - this
should be optional and every developer would have to take care of the used
API. </tt>
 <tt>But projects who need to reduce memory/increase concurrent
sessions always have to except restrictions in the way they program/architect.
</tt>
 <tt>Some things always come with sacrifices and not beeing
able to ever call Label.getText() is not much I expect.</tt>
 <tt>Furthermore tools like Checkstyle or AspectJ can take
care of forbidden API-access so runtime problems are not to be expected
(if the appropiate tools are used).</tt>
 
 <tt>Of course I didn't try anything yet - of other SWT-API
does heavy use of getText than I can forget the idea.</tt>
 
 <tt>I'm aware that layouting issues are a place where
the text is needed - but caching the size of the text should be sufficient
and be far more memory friendly than holding the whole string.</tt>
 
 
 <tt>I'll provide the patches for widgetAdapter and EventAdapter
tomorrow ... leisure time calls :D ...</tt>

Report message to a moderator

Re: Reducing RAP memory consumption (serverside / per session) [message #97370 is a reply to message #97325]

Wed, 09 July 2008 11:55

Stefan Hansel

Messages: 103
Registered: July 2009

Senior Member

Patches can be found here ... 
 <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=240143">https://bugs.eclipse.org/bugs/show_bug.cgi?id=240143</a>
 
 I patched the the widget-ID as well,
this saves 13MB for all Text's and 30MB for the whole application.
 String-IDs would still be possible
but are not taken by default.
 
 Don't know whether it is worth it -
anyway you can decide which changes you apply.
 
 Memory for Text-widgets after both
patches:
 
 Class Name        
                     
                   |
Objects | Shallow Heap | Retained Heap | Retained Heap, % 
 ------------------------------------------------------------ ---------------------------------------------------------- 
 org.eclipse.swt.widgets.Text  
                     
       | 400.000 |   41.600.000 |    96.000.000
|           22,72% 
 |- org.eclipse.swt.internal.widgets.WidgetAdapter
          | 400.000 |   12.800.000 |  
 19.200.000 |            4,54% 
 |  '- org.eclipse.swt.internal.widgets.IdGenerator$IntegerId|
400.000 |    6.400.000 |     6.400.000 |    
       1,51% 
 ------------------------------------------------------------ ----------------------------------------------------------

Report message to a moderator

Re: Reducing RAP memory consumption (serverside / per session) [message #97600 is a reply to message #97370]

Thu, 10 July 2008 15:09

Eclipse User

Originally posted by: rherrmann.innoopract.com

Hi Stefan,

thanks for your patch. We well look into it as soon as time permits.

Cheers,
Rüdiger

stefan.hansel@tolina.de wrote:
>
> Patches can be found here ...
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=240143
>
> I patched the the widget-ID as well, this saves 13MB for all Text's and
> 30MB for the whole application.
> String-IDs would still be possible but are not taken by default.
>
> Don't know whether it is worth it - anyway you can decide which changes
> you apply.
>
> Memory for Text-widgets after both patches:
>
> Class Name | Objects |
> Shallow Heap | Retained Heap | Retained Heap, %
> ------------------------------------------------------------ ----------------------------------------------------------
>
> org.eclipse.swt.widgets.Text | 400.000 |
> 41.600.000 | 96.000.000 | 22,72%
> |- org.eclipse.swt.internal.widgets.WidgetAdapter | 400.000 |
> 12.800.000 | 19.200.000 | 4,54%
> | '- org.eclipse.swt.internal.widgets.IdGenerator$IntegerId| 400.000 |
> 6.400.000 | 6.400.000 | 1,51%
> ------------------------------------------------------------ ----------------------------------------------------------
>

Report message to a moderator

Previous Topic:	Still Problem with IE bug #232799
Next Topic:	TableViewer Scroll-Bug

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Tue Apr 16 09:32:34 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter