Dspace 7.5 performace

[emilio lorenzo]

Hello,

Is there any recomendation to improve the initial load time of Dspace 7
home page ?  We are suffering high load times ( and consistent) at a
production site.   (Lots an lots of cpu and memory available)

The recommendations of
https://wiki.lyrasis.org/display/DSDOC7x/Performance+Tuning+DSpace has
been applied and we have alredy  paid attention to this thread:
https://www.mail-archive.com/dspac...@googlegroups.com/msg14510.html

We wonder if anyone has additional tips. We are running low in ideas.

Thanks



--

[Edmund Balnaves]

I don't know how your proxy is wired up, but I got a benefit from binding the external host name in /etc/hosts to the internal IP - that kept a lot API traffic from hitting the external interface.

The home page generates a lot of API calls.   On my server the ratio is 1 page : 10 API calls overall.

I will be interested to see any ideas on this question.  

[Technologiczny Informator]

Hi,

Are you sure your frontend works in cluster mode?

This issue was recently discussed here:

https://groups.google.com/g/dspace-tech/c/dSHHObckkIc/m/jztWqQpTAwAJ

Regards,

Mariusz

[DSpace Technical Support]

I'd also recommend that anyone using DSpace 7.5 consider enabling the new "caching of server-side rendered pages" feature for anonymous users:

https://wiki.lyrasis.org/display/DSDOC7x/Performance+Tuning+DSpace#PerformanceTuningDSpace-Turnon(orincrease)cachingofServer-SideRenderedpages

Simply put, one of the areas where a site can see slowness (especially to the homepage) is during "server-side rendering".  Each time a user visits your site, the *first* page they receive is flat HTML (which is dynamically built via server-side rendering).  This is a feature of Angular which tries to speed up the initial page by sending immediate HTML while the Javascript app is still downloading... once the Javascript app finishes, it replaces the flat HTML and allows you to interact with the page.

However, on very complex pages or pages with a lot of content (like the homepage) , the server-side rendering can take time/resources to generate that flat HTML *on demand*.   That's why we've added the caching feature to cache these flat HTML pages for anonymous users....it ensures that the server-side rendering runs *less frequently*, and the same flat HTML page can be cached & returned for many anonymous users.  That said, this caching is disabled by default at this time.

We've enabled this caching on https://demo7.dspace.org/ to allow the homepage to load more rapidly.

Take a look at the docs here for more information: https://wiki.lyrasis.org/display/DSDOC7x/User+Interface+Configuration#UserInterfaceConfiguration-CacheSettings-ServerSideRendering(SSR)

Tim

[Sean Kalynuk]

In addition to the performance improvements, enabling server-side caching has also resolved a possible memory leak issue we were experiencing. With PM2 managing Node, and using max_memory_restart, the Node processes would restart about every hour or so. Now everything is stable.

 

For reference, we are using:

 

DSpace 7.5

Node v16.18.1

RHEL 7.9

 

botCache and anonymousCache max were set low at 100 for now just to try things out.

 

--

Sean

 

From: DSpace Technical Support <dspac...@googlegroups.com>
Date: Thursday, July 13, 2023 at 3:29 PM
To: DSpace Technical Support <dspac...@googlegroups.com>
Subject: [dspace-tech] Re: Dspace 7.5 performace

Caution: This message was sent from outside the University of Manitoba.

--
All messages to this mailing list should adhere to the Code of Conduct: https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
---
You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/db51e722-e5bd-4853-b059-925c824b4265n%40googlegroups.com.

[emilio lorenzo]

Thanks for the responses received.

Your suggestions and checks have already been put into action. Some of them showed great promise and have already been implemented.

Currently, the repository is exhibiting "normal" response times, except during episodes of very high traffic. These instances involve certain robots,  traffic fromTurnitin and other data extractors, along with significant institutional load.

Under normal circumstances, we are experiencing a manageable load across the various elements of the  architecture. The backend, frontend, Solr, and database servers are operating at a medium-low usage level. We have also established 8 PM2 threads, among other measures.

As we prepare for the anticipated high-activity peaks in September, we are interested in gathering your insights regarding the most effective strategies for expanding our architecture. It seems that we might have reached the limit of vertical growth. Should we contemplate the addition of a second frontend server? Would this prove beneficial during instances of extremely heavy load? Any guidance or tips you could provide would be greatly appreciated.

Thank you for your ongoing support.

Emilio