Bug #22309
closed
D-Net application is slow
100%
Description
The application deployed in the new server (newdnet-openportal.isti.cnr.it) is slow performing the startup and executing operations like:
for (final Resource res : ResourcePatternUtils.getResourcePatternResolver(resourceLoader).getResources("classpath*:/META-INF/**/pom.xml")) {
…
}
I noticed also that the urls of the resolved classpath resources is:
jar:war:file:/var/lib/tomcat_dnet/8080/webapps/is.war*/WEB-INF/lib/commons-net-3.3.jar!/META-INF/maven/commons-net/commons-net/pom.xml
but it should be (according to the old server):
jar:file:/var/cache/tomcat_dnet/8080/Catalina/localhost/is/WEB-INF/lib/commons-net-3.3.jar!/META-INF/maven/commons-net/commons-net/pom.xml
Probably tomcat has not exploded the WAR in the working dir, Can you fix?
Subtasks
Related issues
Updated by Andrea Dell'Amico over 2 years ago
Non capisco il senso di questa segnalazione. Se il war file non fosse esploso, l'applicazione non partirebbe.
Detto questo, vedo varie stranezze nel modo in cui il war è gestito.
- Non c'è l'autounpack configurato su tomcat, quindi dentro webapps il file
is.warnon è esploso (vale sul vecchio e sul nuovo). - C'è una directory
WEB-INFsottowebapps, con dentro property e classi. Il contenuto è diverso tra vecchio e nuovo, e a occhio quella directory non dovrebbe esistere né da una parte né dall'altra. - Sul nuovo, il file
/var/lib/tomcat_dnet/8080/common/classes/cnr-override.propertiescontiene
msro.wf.mail.message.baseUrl = http://dnet-openportal.isti.cnr.it:8080/is/mvc/ui
Che magari non influisce, ma credo non sia corretto
- La connessione a mysql non ha TLS abilitato (non riguarda il caso, ma non c'è motivo per non attivare TLS)
Io direi di iniziare con:
- Ripristinare la configurazione del garbage collector (e riportare le modifiche allo heap nel playbook, non è accettabile modificare a mano configurazioni gestite via ansible)
- Attivare lo unpack dei war nella configurazione di tomcat (va messa a
Truela variabile e aggiunto, autodeploy: '{{ tomcat_m_webapps_autodeploy }}', unpack: '{{ tomcat_m_webapps_unpack }}'atomcat_m_instances) - Eliminare da
webappsla directoryWEB-INF - Verificare tutti i valori di
/var/lib/tomcat_dnet/8080/common/classes/cnr-override.properties
Updated by Anonymous over 2 years ago
Andrea Dell'Amico wrote in #note-1:
Non capisco il senso di questa segnalazione. Se il war file non fosse esploso, l'applicazione non partirebbe.
Sul filesystem non ci stanno i file del war esploso, e questo associato alla lentezza nelle fasi di ricerca delle risorse mi ha fatto pensare che fosse un problema di deploy dell'applicazione. Come risulta anche dai diversi path delle risorse.
Io direi di iniziare con:
- Eliminare da
webappsla directoryWEB-INF
FATTO
- Verificare tutti i valori di
/var/lib/tomcat_dnet/8080/common/classes/cnr-override.properties
FATTO
Updated by Andrea Dell'Amico over 2 years ago
- Status changed from New to In Progress
- Assignee changed from Tommaso Piccioli to _InfraScience Systems Engineer
Updated by Andrea Dell'Amico over 2 years ago
- Status changed from In Progress to Feedback
- % Done changed from 0 to 100
Fatto. Ora il war file viene espanso sotto webapps allo startup di tomcat, lo heap è settato a 3096MB.
I tempi del restart:
INFO: Deployment of web application archive [/var/lib/tomcat_dnet/8080/webapps/is.war] has finished in [23,840] ms Oct 29, 2021 2:24:23 PM org.apache.coyote.AbstractProtocol start INFO: Starting ProtocolHandler ["http-nio-127.0.0.1-8080"] Oct 29, 2021 2:24:23 PM org.apache.tomcat.util.net.NioSelectorPool getSharedSelector INFO: Using a shared selector for servlet write/read Oct 29, 2021 2:24:23 PM org.apache.catalina.startup.Catalina start INFO: Server startup in 23932 ms
Updated by Andrea Dell'Amico over 2 years ago
FYI: non so se l'incremento dei tempi di startup sia dovuto allo autoUnpack (che è attivo di default sulle installazioni smartgears, ma disattivato in praticamente tutte le installazioni dnet a parte quella di ariadne e poche altre, perché non sono state aggiornate le configurazioni dopo che ho cambiato il default qualche anno fa) o al fix in cnr-override.properties. Se serve si verifica facilmente.
Updated by Anonymous over 2 years ago
Il fix cnr-override properties non credo sia collegato al problema di lentezza, quella property è un parametro del template di una mail, potrebbe contenere qualsiasi stringa.
Comunque bene così siamo passati da 15 minuti a 24 secondi.
Updated by Anonymous over 2 years ago
- Status changed from Feedback to Closed
Anche il wf di trasformazione di ISPC che prima impiegava 20 minuti, ora ha impiegato 7 secondi.
Chiudo il ticket.
Updated by Andrea Dell'Amico over 2 years ago
Sto facendo il test, giusto per curiosità, e posso confermare che unpackWars fa la differenza.
Updated by Andrea Dell'Amico over 2 years ago
Abuso di questo ticket per aggiungere che ho cambiato il playbook in modo da creare utenti non privilegiati per me e Tommaso su tutte le macchine: gli accessi diretti come root dovrebbero essere evitati.