Portlet di ricerca, dimensionamento hardware e prestazioni

thumbnail
Marco Azzalini, modified 6 Years ago. Regular Member Posts: 146 Join Date: 11/18/14 Recent Posts
Ciao, come da oggetto, volevo chiedere consiglio alla comunity su come parametrizzare al meglio il portale per velocizzare al massimo le ricerche. So che esiste un collo di bottiglia intrinseco dovuto al fatto che LR deve analizzare a posteriori i risultati ottenuti da Lucene per verificarne i permessi di visibilità rispetto all'utente che effettua la ricerca ma al di la di questo vorrei assicurarmi di aver fatto quanto possibile.
Attualmente il portale gira su un server con 8GB di RAM e 2 CPU (Intel Xeon@ 2.60GHz - 4 core), caricati dentro ci sono circa 5000 documenti e (senza utenti) una ricerca corposa (n. di risultati  >  300-400 ) impiega circa 30-40 (ma può arrivare a 50) secondi che francamente mi sembrano troppi. Ho configurato il portale seguendo varie indicazioni, in particolare quelle di Surekha, e relativamente alla JMV, l'ho impostata così:
JAVA_OPTS="$JAVA_OPTS -XX:NewSize=700m -XX:MaxNewSize=700m -Xms2048m -Xmx2048m -XX:MaxPermSize=512m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:SurvivorRatio=20 -XX parallelGCThreads=8"


Ho notato che durante le ricerche l'occupazione di RAM arriva vicino al 90% (di solito è intorno al 50%) quindi sto valutando di aumentare la RAM e passare a 4GB per la JVM, ritenete che questo possa effettivamente dare dei benefici per i tempi di ricerca o sarebbe necessario aumentare anche la CPU?
Posso configurare specificatamente qualcosa anche lato Lucene per ottimizzare i tempi di risposta? Grazie in anticipo per ogni consiglio che mi darete :-)ciaoMarco
thumbnail
Daniele Baggio, modified 6 Years ago. Expert Posts: 336 Join Date: 12/5/08 Recent Posts
ciao,a sentimento non la farei una questione di ram, non solo almeno.
Credo sia da capire il contesto in modo migliore: come sono indicizzati i documenti, come viene fatta la ricerca, che paginazione è impostata, cosa sta facendo la cpu,  quanti thread sono occupati, che carico di sessioni ci sono, etc etc...
thumbnail
Marco Azzalini, modified 6 Years ago. Regular Member Posts: 146 Join Date: 11/18/14 Recent Posts
Ciao Daniele, ho aspettato a rispondere perché nel frattempo la cosa è evoluta ed ho trovato il motivo di tanta lentezza ;-) Diciamo che era dovuto ad una buona  combinazione di incasinamento del Portale ed degli indici di Lucene, tanto che una ricostruzione degli indici impiegava tempi biblici a causa di un errore ma senza che questo risultasse nei log.Alla fine di tutto questo le ricerche ora vengono eseguite in un decimo del tempo di prima e con una minima occupazione di memoria, quindi tutto bene.... o quasi :-)Mi si aprono però due nuovi problemi, uno di tipo sistemistico e uno forse più di tipo software:1) Schedulare una ricostruzione settimanale degli indici? E' buona pratica con Liferay? Al momento non sono riuscito a trovare indicazioni precise in merito nella documentazione ufficiale...2) Mi sono accorto che può capitare che la ricostruzione dell'indice vada in errore (come in quest'ultimo caso) a fronte della cancellazione di qualche asset, ovvero il processo si blocca lamentando che non esiste l'asset entry per il classNameId ...  e classPK ... ma è giusto che non ci sia dato che è stata cancellata una entity con gli asset e le resources associate, quindi da dove piglia questi riferimenti? E perché la mancanza di un asset deve bloccare l'intero processo di indicizzazione?
Sperando di essere riuscito a spiegarmi, mi piacerebbe sentire la tua (o di altri)  opinione in merito

ciao e grazie
Marco
thumbnail
Daniele Baggio, modified 6 Years ago. Expert Posts: 336 Join Date: 12/5/08 Recent Posts
Ok grazie per il feedback.

Schedulare il reindex? Non vedo nulla di male a farlo in un momento dove il portale non lavora. Diciamo che non dovrebbe servire normalmente.

Per il problema dell'errore dato dalla mancanza di asset direi che la cancellazione dell'asset non è stata fatta completamente e restano dei riferimenti. Dato che il reindex si basa solo sui contenuti del db, il db deve essere pulito e coerente direi.
thumbnail
Marco Azzalini, modified 6 Years ago. Regular Member Posts: 146 Join Date: 11/18/14 Recent Posts
Si, hai naturalmente ragione sul fatto che il DB deve essere pulito ed integro ma qui il problema mi nasce dal fatto che indicizzando mi viene sollevato un errore relativo alla mancanza di un asset, mancanza che effettivamente io constato nel  DB e che quindi mi 'certifica' che la cancellazione dell'asset (e dell'entity) è avvenuta regolarmente e nonostante questo mi viene riportato una indicazione precisa dell'assetentry mancante, che non può a questo punto  venire dalla tabella assetentry perché li non c'è più.... sembra un po'  la storia del cane che si morde la coda :-) Ad ogni modo, quando mi succederà ancora cercherò di raccogliere più informazioni che posso e mi rifaccio vivo.