We are currently evaluating / prototyping an Aikau / Dojo-based portal solution using Alfresco Share as the basis. We currently have 22 Aikau-based pages (primarily table-based master data management) of which 16 have some variation in widget composition based on the role of the current user.
During developer testing it has been observed that the Share application will begin to slow-down (response times) after 10-15 unique page visits with different widget compositions have occurred. At the same time, the JVM starts to consume more CPU time for garbage collection.
Analysis of the heap usage shows that the DojoDependencyHandler retains a lot of heap by holding the generated resources in a purely in-memory cache. This is a very poor design. The generate resources will be aggregates of an arbitrary number of source files and also include a high level of redundancy as multiple aggregates may contain the same sub-set of source files. In one of our tests, 11 cached resource aggregates already retain about 68 MiB.
Any generated resources - compressed or uncompressed - should not be cached purely in-memory without providing any kind of cache size control for system administrators. Preferably, generated resources are cached on disk (in application server work or temp directory). This might also allow some degree of cache persistence across restarts, reducing first page load times for Aikau pages.
As it stands, a Share tier that uses Aikau pages needs to be allowed a significantly higher max heap memory (-Xmx JVM parameter) compared to non-Aikau based Share to reduce chance of OOM errors and GC overhead.