Contribute to the DSpace Development Fund

The newly established DSpace Development Fund supports the development of new features prioritized by DSpace Governance. For a list of planned features see the fund wiki page.

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

Compare with Current View Page History

« Previous Version 10 Next »

During the DevMtg on Oct 13, 2022, we began a discussion on improving the performance of the DSpace 7 UI, especially in terms of initial load.  This page is meant to gather information / notes for further analysis

Overview

Goal is to improve the initial load of the UI per user reports and Google Lighthouse analysis (see screenshot)


DSpace 7 UI Infrastructure Examples

DSpace 7 Demo Site UI infrastructure

TODO: Art Lowel (Atmire) or Atmire provide details on the infrastructure behind https://demo7.dspace.org/ (DSpace 7 Demo UI), especially in terms of the Node.js setup/configuration and setup/configuration of proxies.

NOTE: Here's the Google Lighthouse performance as of Oct 13, 2022:

DSpace-CRIS 7 Demo Site UI infrastructure

TODO: Andrea Bollini (4Science) or 4Science provide details on the infrastructure behind https://dspace-cris.4science.cloud/ (DSpace-CRIS 7 Demo UI), especially in terms of the Node.js setup/configuration and setup/configuration of proxies.

NOTE: On Oct 13, 2022, DSpace-CRIS 7 demo site has better Performance results from Google Lighthouse than DSpace 7 Demo site:


TU Berlin DSpace 7 UI infrastructure

Google Lighthouse performance results for https://depositonce.tu-berlin.de on October 14, 10:20am:

Our servers run at the university's IT department in an Open Stack environment with these specs:

ServerCoresRAM
Backend1664GB
Frontend832GB
PostgreSQL416GB
SOLR28GB

 This is our PM2 configuration file:

dspace-ui.json
{
  "apps": [
    {
      "name": "dspace-ui",
      "cwd": "/srv/dspace-ui-deploy",
      "script": "dist/server/main.js",
      "node_args": "--max_old_space_size=8192",
      "env": {
        "NODE_ENV": "production",
        "DSPACE_REST_SSL": "true",
        "DSPACE_REST_HOST": "api-depositonce.tu-berlin.de",
        "DSPACE_REST_PORT": "443",
        "DSPACE_REST_NAMESPACE": "/server"
      }
    }
  ]
}


The frontend runs behind an Apache proxy, as described in the Installing DSpace page.

The backend also runs behind an Apache proxy, as described in the Installing DSpace page. I increased the Java memory significantly:

Environment="JAVA_OPTS=-Djava.awt.headless=true -Xmx8G -Xms2G -Dfile.encoding=UTF-8"

Optimization Strategies

Node.js configuration for multi-threading

TODO Andrea Bollini (4Science) mentioned in the meeting on Oct 13, 2022 that 4Science has discovered that the default setup of Node.js can be limiting for sites with a lot of users simply because Node.js is single threaded.  He noted that 4Science has found ways to configure Node.js to better support many users by allowing Node.js to use all your CPU, etc.   Those configurations / setup should be documented here

Minimize size of main.js 

TODO Team needs to investigate if there are ways to further minimize the size of the main.js file (noted by Lighthouse as being too large) via lazy loading or similar strategies. 

Examples: https://christianlydemann.com/the-complete-guide-to-angular-load-time-optimization/

This might  require optimizing pages which users are most likely to first access the application.  Namely:

  • Homepage
  • Item splash pages
  • (Possibly others? Community/Collection splash pages?)

Tools

webpack-bundle-analyzer

Can be used to visualize what is taking up a lot of space in main.js and other bundles

https://www.npmjs.com/package/webpack-bundle-analyzer

Running for DSpace:

  • Install it (globally):    npm install -g webpack-bundle-analyzer
  • Run a build and generate stats.json:   yarn build:stats
  • Start it up!    webpack-bundle-analyzer .\dist\browser\stats.json


BundlePhobia.com

Useful to find the normal size of dependencies & links you to alternative libraries which may be smaller: https://bundlephobia.com/

It also details which libraries are "tree shakable" and which are not.



  • No labels