You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Status Quo

Running performance tests against M5 (beta2) we got the impression that M5 is consuming quite a lot of memory per user. That's why we wanted to optimize.

 

Analysed Components 

ContentApps + containers

tree
list
thumbnail
  • doesn't extend AbstractJcrContainer - hence it cannot use its paging mechanism
  • has its own lazy loading mechanism: loads when required but then keeps all read items (images) until we switch to another view

Setup

For the analysis we used the contacts app. There we added 10'000 contacts all having a random street (2000 chars), city (100 chars) + organization name (20'000 chars) as well as one identical image (11kbyte). See attached script for further details.

Results

  • starting contacts app consumes 20-30 MByte of additional memory
    • could not measure a diff between querying "select *..." of "select [jcr:uuid]..." in AbstractJcrContainer#updateSize()
  • list view temporarily consumes about 100 MByte but this goes aways on GC - this is true even when scrolling around
  • thumbnail view consumes about 200 MByte when scrolling in it - this memory stays after GC and is only freed when switching to another view

 

  • No labels