Problemas de rendimiento Liferay 6.1.1

[Sergio Belmar, modificado hace 10 años.]

Hola,

Estoy configurando un entorno con Liferay y estoy teniendo problemas de rendimiento.

Usando jmeter, para cargar la página principal, con unas 100 peticiones por minuto, tengo unos tiempos de respuesta muy pobres. Si subo a 200 peticiones por minuto, los tiempos de respuesta se ponen en medias de 20-30 segundos. Además, en estas condiciones, el consumo de CPU se pone al máximo.
Además, el añadir miembros al cluster de Liferay no mejora el rendimiento.

La configuración ahora mismo es, siguiendo, los esquemas de alta disponibilidad de liferay, la siguiente:

Balanceador de carga externo proporcionado por el hosting.
2 apaches balanceados.
2 Liferay con el paquete Tomcat, configurados en cluster.
Una unidad NFS en un servidor independiente para el repositorio.
Un cluster de galera-mysql con un proxy y 3 nodos (configuración multimaestro, todos pueden escribir).

Las máquinas donde está el Liferay tienen 6GB de RAM y 8 cores cada una, el resto, son de 1-2 cores con 1-2 gb de RAM.

La configuración de java que estoy usando ahora mismo (despues de multiples pruebas):
JAVA_OPTS="$JAVA_OPTS -Dfile.encoding=UTF8 -Dorg.apache.catalina.loader.WebappClassLoader.ENABLE_CLEAR_REFERENCES=false -Duser.timezone=GMT -XX:+UseConcMarkSweepGC -Xms2048m -Xmx4096m -XX:NewSize=700m -XX:MaxNewSize=700m -XXermSize=256m -XX:MaxPermSize=1024m -XX:SurvivorRatio=10 -XXarallelGCThreads=8 -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled"

Si alguien me puede echar un cable, os lo agradecería.
Adjunto el fichero portal-ext .properties. Si hace falta cualquier otro fichero de configuración o cualquier aclaración, por favor pedídmelo.

He probado a hacer las tipicas optimizaciones que aparecen el los foros y no he notado ninguna mejoría. La base de datos la configuro desde el archivo "tomcat-7.0.27/conf/Catalina/localhost/ROOT.xml"
No he podido hacer un profiling por problemas con el hosting.

Un saludo y muchas gracias.

[Julio Varela Gómez, modificado hace 10 años.]

Buenas Sergio,

Mira este documento haber si te sirve de ayuda.

http://www.liferay.com/documents/14/8440800/Advanced+Liferay+Architecture-Clustering+and+High+Availability.pdf

[Sergio Belmar, modificado hace 10 años.]

Gracias Julio,

En un principio usé ese documento para la configuración, voy a revisarlo por si dejé alguna cosa sin configurar correctamente.

Gracias por la ayuda

[Julio Varela Gómez, modificado hace 10 años.]

Buenas Belmar,

Con la información que has puesto seguro que responde Sergio Sánchez, he tenido el gusto en conocerle y es un especialista en este tipo de problemas.

Comentar que le echado un vistazo al log:

En cuanto al error que se observa:
06:32:47,690 ERROR [pool-2-thread-1][HookHotDeployListener:1526] Unable to read portal.properties
com.germinus.easyconf.ConfigurationNotFoundException:.....
........

A lo mejor este enlace del foro os da alguna pista. http://www.liferay.com/es/community/forums/-/message_boards/message/10843877

En cuanto al número de portlets en portada 21 (13 de ellos publicadores) creo que puede hacer que este siendo una página algo pesada, pero esto te lo podrá decir mejor Sánchez. Yo te diría en vez de probar solo contra portada que hagas esta prueba de carga contra otra página del portal, donde contenga un número inferior de portlets y viendo si se producen resultados optimos. O realiza una simulación de navegación de esos hilos de usuarios por varias página para ver si es la portada en cuello de botella.

Un saludo.

[Sergio Belmar, modificado hace 10 años.]

Hola Julio,

La verdad es que encantado con la atencio en el foro, la verdad...

Miraré ahora en enlace para lo del error que mandas, gracias.

Si hago las mismas pruebas sobre una página que no sea la portada, si que obtengo mejores resultados, pero tampoco espectaculares: adjunto un pantallazo de 100, 200 y 300 peticiones por minuto (esta última ni siquiera llega a atender las 300 peticiones).

La página será una especie de revista digital y la portada es bastante importante (y grande).

Un saludo y muchas gracias.

[Sergio Sánchez, modificado hace 10 años.]

Hola Sergio, un rendimiento de 1,6 paginas por segundo es bastante pobre sí.

¿Cómo es la prueba que has diseñado? ¿Has incluido 100 hilos supongo? ¿Has incluído un periodo de rampa y tiempos de espera entre las peticiones?
Y además sobre la página, ¿tiene muchos portlets la portada? ¿Qué tipo de portlets son?
Sobre el fichero portal-ext, no veo en principio nada que pudiera afectar al rendimiento. He comprobado que las cachés más determinantes están activas.
¿Podrías pasarnos también el log de arranque del portal?

Entiendo que no puedes vincular un Visual VM o jconsole a la JVM.
Para acotar un poco qué está haciendo el servidor, puedes lanzar threaddumps cada 5 segundos cuando el servidor se empiece a saturar para irlos comparando y ver en que se puede estar quedando bloqueado el servidor.
Te paso un pequeño script que te puede ayudar a generarlos:

#!/bin/bash

for i in {1..20}
        do
                jstack `jps | grep Bootstrap | awk '{print $1}'` > td-$i.log;
                sleep 5;
        done

Si quieres, puedes compararlos con alguna utilidad como kdiff3 y ver la evolución en el tiempo o los comprimes en un zip y les echo un ojo.

Un saludo

[Sergio Belmar, modificado hace 10 años.]

Hola Sergio,

La prueba básica es muy sencilla: simplemente con Jmeter, 100 hilos y el periodo de subida 60 segundos.
Con esto me da las 1,4 - 1.6 peticiones por segundo, pero con unos tiempos de media muy grandes, te adjunto un ejemplo del resultado.
Si subo el número de peticiones, o bajo el tiempo, se me van mucho más lejos los tiempos, con medias de 10 - 20 segundos mínimo.

En cuanto a los portlets de la portada, ahora te contesto cuando me lo digan desde desarrollo, para mi es casi una caja negra, lo que complica las cosas...

Te adjunto el log del catalina en el arranque.

Efectivamente, no he podido conectar el visualVM al liferay remoto, a pesar de ver el puerto abierto en el servidor, de tenerlo en el Firewall y de poder conectarme por telnet, no puedo conectarme con el visualVM. Intentaré montar a lo largo de la semana una copia reducida en un vmware local para ver si puedo hacerle un profiling.

Mientras, probaré a ejecutar el script que has mandado y te comento los resultados.

Muchas gracias por la ayuda y un saludo.

[Sergio Belmar, modificado hace 10 años.]

Hola, adjunto la estructura actual del desarrollo:

Publicadores de contenidos: 13, cada uno con sus filtros específicos.
Visores de contenido web: 4, 3 de ellos embebidos a través del tema de apariencia.
Nube de tags: 1.
Visor de encuestas: 1.
Buscador: 1, embebido a través del tema de apariencia.
OpenGadget: 1.

Si hace falta algo más, pedídmelo por favor.

Un saludo y gracias.

[Sergio Belmar, modificado hace 10 años.]

Hola Sergio Sánchez,

Te adjunto un zip con los ficheros td-x.log generados con el script que me mandaste ayer:

Le he hecho 200 peticiones en 30 segundos para poner la CPU al 100%.
La verdad es que no sé como interpretarlos, si me explicas un poco, veré como hacerlo.

Muchas gracias

[Sergio Belmar, modificado hace 10 años.]

Añado la configuracion del server.xml del tomcat:

<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" URIEncoding="UTF-8" maxHttpHeaderSize="8192" maxThreads="1000" minSpareThreads="50" maxSpareThreads="50" enableLookups="false" acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true"/>

Se monta con un apache a través de jk.

Saludos.

[Sergio Belmar, modificado hace 10 años.]

Pongo tb. el $CATALINA_HOME/conf/ Catalina/localhost/ROOT.xml con el conector a la base de datos:

<Resource auth="Container" description="Portal DB Connection" driverClass="com.mysql.jdbc.Driver" maxPoolSize="150" minPoolSize="20" acquireIncrement="10" name="jdbc/LiferayPool" user="usuario" password="password" factory="org.apache.naming.factory.BeanFactory" type="com.mchange.v2.c3p0.ComboPooledDataSource" jdbcUrl="jdbc:mysql://IP:3306/db?useUnicode=true&amp;characterEncoding=UTF-8&amp;useFastDateParsing=false"/>


Además aprovecho para preguntar: para la conexion jmx para usar el visualVM, he configurado esto en el setenv.sh
You may add the following to you application server’s JVM arguments to enable JMX connections:
-Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.port=5000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false

El puerto 5000 está escuchando: netstat -aton | grep 5000 tcp 0 0 0.0.0.0:5000 0.0.0.0:* ESCUCHAR
He abierto el puerto 5000 en el firewall remoto (me puedo conectar haciendo un telnet al puerto 5000 de la IP publica)
Pero lanzo el visualVM, le añado un host remoto con la IP pública y cuando añado una conexion JMX all puerto 5000 me da error de que no puedo conectar.
¿Hay algún puerto que deba tener abierto o algún detalle que se me esté pasando? Si esto funcionase seguro que podría avanzar algo más.

Gracias

[Iñaki Sainz, modificado hace 10 años.]

Hola Sergio,

de los thread dumps desprendo que debes tener algún tipo de problema en el File system. S te fijas, en los thread dump que ocupan más tamaño hay numeros threads esperando a un bloqueo sobre java.io.UnixFileSystem.canonicalize ...

	at java.io.ExpiringCache.get(ExpiringCache.java:55)
	- waiting to lock <0x00000006ebc07c98> (a java.io.ExpiringCache)
	at java.io.UnixFileSystem.canonicalize(UnixFileSystem.java:137)
	at java.io.File.getCanonicalPath(File.java:559)
	at sun.security.provider.PolicyFile.canonPath(PolicyFile.java:1834)
	at java.io.FilePermission$1.run(FilePermission.java:186)
	at java.io.FilePermission$1.run(FilePermission.java:183)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.io.FilePermission.init(FilePermission.java:183)

Lo curioso es que el resto de la petición no es la misma en todos los casos, por lo que pienso que es algo relacionado con la infraestructura más que con el código.

Una búsqueda rápida en Google no me ha dicho gran cosa, pero por lo que he visto la gente se queja de cuelgues relacionados con NFS o con problemas de máquina virtual i/o kernel.

Lo primero que te diré es que si el servidor de aplicaciones o su directorio de trabajo (no los repositorios de DL) el temp, work etc... los tienes en un NFS pueden ser el origen del problema. Sería conveniente tenerlos en algún otro tipo de almacenamiento.

En cualquier caso, te diría de hacer una prueba simple. Para los servidores y borra el contenido de temp y work. En ocasiones he tenido problemas raros derivados del volumen de ficheros de un directorio, y merece la pena intentarlo.También podrías hacerlo sobre los logs, pero no tiene pinta de ser ese el problema.
Investiga a través del comando iostat de unix si tienes muchos bloqueos y el uso de CPU del mismo, si tienes espacio en el punto de montaje, etc...

En otro ámbito de cosas, me ha parecido entender que tienes 21 portlets de tipo asset publisher en la portada? Eso es un tamaño considerable de información y indudablemente te va a originar problemas. Quizá no esté en tu mano reducirlo (la decisión sea originaria de otro), pero una portada más ligera seguro que te ayuda a tener un mejor rendimiento.

A ver si alguno de estas cosas te ayuda.

Suerte.

[Sergio Belmar, modificado hace 10 años.]

Gracias Iñaki.
Probaré también a revisar la unidad de disco.

En cuanto a los portlets, a ver que puedo negociar con desarrollo, hehehe.

Muchas gracias, el lunes podré probar estas cosas.

[Sergio Belmar, modificado hace 10 años.]

Buenos días,
Tengo una pregunta más: estoy usando la versión "Liferay Portal Community Edition 6.1.1 CE GA2 (Paton / Build 6101 / July 31, 2012)".
En cuanto a rendimiento, ¿hay alguna limitación (aparte de los módulos exclusivos como el almacenamiento con Documentum o el algoritmo de cache distribuida con respecto a la EE?
Tengo la duda de seguir dándole vueltas a esto y que no pueda obtener un buen rendimiento por usar la versión CE.

Gracias.

[Iñaki Sainz, modificado hace 10 años.]

Las versiones CE no tienen limitaciones en rendimiento.

Lo que si te puedes encontrar son bugs que afecten a rendimiento y que solo se arreglen para la versión EE o para la siguiente CE (en tu caso la 6.2). Pero aún así, podrías bajarte el código de la 6.1, y alterarlo tu mismo para solucionar ese bug o cualquier otro.
Es una de las ventajas del open source.

[Sergio Belmar, modificado hace 10 años.]

Hola Iñaki,

He probado borrando los logs y el contenido del directorio temp.
Además, he desmontado el directorio y copiado los datos a una ruta local (como solo tengo 1 tomcat funcionando, no tengo que poder compartirlo).

El rendimiento es muy similar, diría que idéntico.
Adjunto los thread dumps sin usar nfs.

Un saludo.

[Iñaki Sainz, modificado hace 10 años.]

Hola Sergio,

El comportamiento de los threadas ha variado, ahora ya no parece que haya threads que se bloqueen unos a otros.

El problema es que ahora aparecen todos en consultas que se realizan a la base de datos. Casi todos los threads aparecen esperando a respuesta de la base de datos. Hay ciertas cosas habituales que deberías revisar por si acaso:

- Están los índices creados en la base de datos. Especialmente los relativos a las tablas de Assets y Tags que son donde realizas la mayor parte de consultas.
- También puedes revisar que las queries que se lancen vayan rápidas, si no es así, quizá tengas que hacer un mantenimiento de la base de datos y recalcular estadísticas, índices, etc...
- Si te lo puedes permitir por requerimientos, prueba a deshabilitar esta variable:
#
# Set this to true to enable incrementing the view counter for assets.
#
asset.entry.increment.view.counter.enabled=true

Eliminarás los update a base de datos para el contador de visitas.

Por último, te recomiendo que intentes averiguar cuales con las queries que tardan más tiempo, ya se a través de analizar lo que tardan los métodos (visualvm), analizando los logs o sistemas de la base de datos, o sencillamente poniendo algun tipo de herramienta tipo p6spy que te trace el tiempo de las consultas.

Ya nos dirás con lo que descubras.

[Sergio Belmar, modificado hace 10 años.]

Hola Iñaki,

Gracias por las indicaciones, tendré que darle una vuelta a la base de datos.
He desactivado el contador de accesos.
Sigo intentando también ver si puedo conectar el visalvm...

Para el disco del repositorio, ¿que recomendáis, en lugar de NFS? ¿CIFS con samba?

Muchas gracias y un saludo.

[Sergio Belmar, modificado hace 10 años.]

He dejado funcionando una replica de mi entorno (con un solo liferay y un solo apache, tengo recursos limitados) y en local he podido activar el visualVM.

Le he hecho una prueba de 200 peticiones con rampa de 60 segundos en Jmeter y lo he monitorizado, pongo el resultado del Jmeter y la pantalla principal del visualVM:

¿Me podríais dar alguna indicación de como usar esta herramienta para optimizar esto?

Muchas gracias

[Sergio Belmar, modificado hace 10 años.]

Otra cosa que veo es que con el sistema en reposo total, la gráfica sigue con dientes de sierra.

[Iñaki Sainz, modificado hace 10 años.]

Es normal, Liferay tiene sistemas que se ejecutan en segundo plano y se activan periódicamente cada poco tiempo para comprobar cosas (cron jobs de Quartz).

[Iñaki Sainz, modificado hace 10 años.]

Hola Sergio,

Varios puntos.

Quizá la información que más te va a interesar ahora mismo no es la de consumo de memoria si no la de consumo de tiempos de CPU. Pestaña Sampler --> cpu y mirar que métodos de Liferay consumen más tiempo. Así sabrás cuales son las queries que más tardan.

De tus gráficas se desprende que la CPU se dispara y la memoria no, lo que indica que simplemente tus métodos tardan mucho en procesarse y necesitas más CPU para la carga que tienes actualmente. Dos opciones, o pones más CPU o mejoras el código para que vaya más rápido.
He visto que tu petición más corta tarda 3000ms... me parece mucho para la petición más rápida eso me indica que tu portal, de por si solo ya es lento (sin carga) Por tanto, optimiza el código y el acceso a la base de datos.

Si siempre te tarda tanto, deberías concentrarte en rebajar ese tiempo para una única petición. Cuando tengas un rendimiento óptimo de una petición entonces aplica carga para ver como se comporta.

Para ello, te recomiendo que mires que consultas tardan más con las pestaña sampler y añade un filtro para com.liferay para ver solo clases de Liferay. Sabrás que métodos tardan más y se invocan más. Concentra tus esfuerzos ahí.
Si confirmas que el problema se encuentra en las queries que se lanzan, utiliza el software p6spy para mirar las queries que más tardan. Es muy sencillo de configurar y te mide los tiempos de cada query lanzada.
No te olvides de optimizar la base de datos. Puede que falte un índice o sencillamente que necesite un mantenimiento mínimo.

Fuera de todo esto, que son generalidades, no hay ningún botón mágico que lo apretas y ya está. 13 asset publisher son muchos, especialmente si tienes mucha información con lo que deberías centrarte en que fueran lo más rápido posible.

Slds.

[Sergio Belmar, modificado hace 10 años.]

Gracias Iñaki, lo voy mirando, adjunto los procesos que más CPU consumen.

Si le lanzo una petición nada más, me tarda unos 2 segundos.
He probado a generar un portal con menos portlets y sí que tiene mejores resultados, aunque siguen siendo malos.

También me temo que tenga problemas con la caché.

Voy a seguir haciendo pruebas.

[Sergio Belmar, modificado hace 10 años.]

Ya tengo configurado el visualVM en el entorno de producción, con lo que ya puedo hacer pruebas más reales:

Tras lanzarle unas 6000 peticiones en 1 hora (con tiempos de respuesta de 8 segundos de media), los procesos que más memoria consumen son los que adjunto, la verdad es que no sé si es normal.

Los esfuerzos los estamos dirigiendo a mejorar los tiempos de una consulta primero, ya que tarda eso, entre 2 y 3 segundo, para luego pasar a ver que tal va aumentando la carga, ya sea optimizando las consultas a la base de datos o reduciendo portlets, u optimizando las modificaciones realizadas...

Probé a asignar el doble de recursos: 16 cores y 8 GB de RAM y los tiempos de respuesta no varían apenas.

También he activado el p6spy pero me devuelve demasiada información (simplemente con el proceso de arranque y una visita a la portada, me genera un log de 4 megas) y tampoco veo los tiempos que tarda:

Por ejemplo:
1377172679933|-1||resultset| SELECT AssetCategory.categoryId as categoryId71_0_, AssetCategory.uuid_ as uuid2_71_0_, AssetCategory.groupId as groupId71_0_, AssetCategory.companyId as companyId71_0_, AssetCategory.userId as userId71_0_, AssetCategory.userName as userName71_0_, AssetCategory.createDate as createDate71_0_, AssetCategory.modifiedDate as modified8_71_0_, AssetCategory.parentCategoryId as parentCa9_71_0_, AssetCategory.leftCategoryId as leftCat10_71_0_, AssetCategory.rightCategoryId as rightCa11_71_0_, AssetCategory.name as name71_0_, AssetCategory.title as title71_0_, AssetCategory.description as descrip14_71_0_, AssetCategory.vocabularyId as vocabul15_71_0_ FROM AssetCategory INNER JOIN AssetEntries_AssetCategories ON (AssetEntries_AssetCategories.categoryId = AssetCategory.categoryId) AND (AssetEntries_AssetCategories.entryId = 75530) |descrip14_71_0_ = <?xml version='1.0' encoding='UTF-8'?><root available-locales="es_ES" default-locale="es_ES"><Description language-id="es_ES">Bloque 2 de Noticias Medias</Description></root>, name71_0_ = Bloque 2, title71_0_ = <?xml version='1.0' encoding='UTF-8'?><root available-locales="es_ES" default-locale="es_ES"><Title language-id="es_ES">Bloque 2</Title></root>, userName71_0_ = Admin Voces Default, uuid2_71_0_ = e9e0e83e-8a31-459a-9204-86fdaed6cd96

Cualquier ayuda será bienvenida.

[Sergio Sánchez, modificado hace 10 años.]

Hola Sergio, aquí estoy de vuelta de vacaciones.

Te voy diciendo de momento lo que he visto...

He estado revisando los threaddumps, y hay mucha lógica de acceso a base de datos pare recuperar etiquetas y categorías (Se observan invocaciones a métodos del tipo AssetTagFinderImpl.doFindByG_C_N())

Se ha mejorado el rendimiento de esos métodos ofreciendo cacheo en la capa de persistencia a través del ticket LPS-33918.

Te voy contando que más veo...

[Sergio Sánchez, modificado hace 10 años.]

Se observan también múltiples llamadas a AssetEntryServiceImpl.incrementViewCounter

Se trata de un método costoso desde el punto de vista del rendimiento y si no utilizáis el contador de visitas para cada artículo, documento, ... podéis deshabilitarlo como te comentó Iñaki.

[Sergio Sánchez, modificado hace 10 años.]

Más cosas, se observa un overhead significativo en el método PACLClassUtil._getPACLPolicyBeanByReflection()

Esta clase forma parte del gestor de seguridad para los plugins de Liferay adquiridos a través del Marketplace.
Come en el caso anterior en el que chocaban funcionalidad y rendimiento, aquí chocan seguridad y rendimiento. Es recomendable utilizarlo, aunque es posible desactivar este security manager si los plugins que se utilizan no es necesario que sea verificada cada llamada a la API que realizan.

En la próxima release de Liferay 6.1 GA3 se ha hecho más eficiente esta implementación por lo que sería muy recomendable actualizarse a ella una vez se libere (también incluiría el arrreglo para el LPS que te mencioné anteriormente de categorías y etiquetas)

[Sergio Sánchez, modificado hace 10 años.]

Sobre los asset publishers... ¿hay 13 en la portada según he entendido?
¿La portada tendría más visitas con navegación anónima que autenticada?
Si es así sería interesante que la portada pudiera ser servida a través del CacheFilter que cachea todo el HTML de la página en navegación anónima.
Para ello, todos los portlets presentes en esa página tienen que cumplir que en su descritptor liferay-portlet.xml estén identificados como cacheables:
<layout-cacheable>true</layout-cacheable>
El asset publisher lo es, pero si tenéis algún otro portlet que no lo sea, una buena idea podría ser sacar a ese portlet a otra página y beneficiarse del uso del CacheFilter.

Espero que sirvan estos consejos...

Un saludo.

[Sergio Belmar, modificado hace 10 años.]

Holas,

Si, hay 13 asset publishers en la portada.
Si, la portada tendría más visitas con navegación anónima que autenticada, es una especie de periodico digital.

Comento con desarrollo a ver si los portlets están identificados con cacheables.

Gracias, y un saludo.

[Sergio Belmar, modificado hace 10 años.]

Una nueva cuestión:

Al comienzo del log del Tomcat, me muestra este mensaje:

INFO: La biblioteca nativa de Apache Tomcat basada en ARP que permite un rendimiento óptimo en entornos de desarrollo no ha sido hallada en java.library.path:

¿Recomendáis instalar esta librería? Realmente este mensaje me ha pasado desapercibido casi hasta ahora...

También me salta un aviso para que actualice ehcache: tengo la 2.2.0 y he visto que está disponible la 2.6.7, ¿recomendáis actualizarlo o puede haber algún problema de compatibilidad con la version de liferay?

Gracias y un saludo.

[Sergio Belmar, modificado hace 10 años.]

Hola de nuevo,

¿Hay alguna forma de desactivar (por lo menos para hacer la comparativa) el gestor de seguridad para los plugins de Liferay?

Gracias y un saludo.

[Sergio Belmar, modificado hace 10 años.]

Hola Sergio e Iñaki, me imaginaba que estarías de vacaciones.

Gracias por la ayuda, te voy contestando a lo que me dijiste ayer según las vaya probando:

¿Es posible que haya muchas consultas del tipo "AssetEntryServiceImpl.incrementViewCounter" si ya tengo la propiedad asset.entry.increment.view.counter.enabled a false?

Gracias y un saludo.

[Sergio Sánchez, modificado hace 10 años.]

Sergio Belmar:

¿Es posible que haya muchas consultas del tipo "AssetEntryServiceImpl.incrementViewCounter" si ya tengo la propiedad asset.entry.increment.view.counter.enabled a false?

¿Reiniciaste el portal tras cambiar el valor en portal-ext.properties?
¿Se sigue observando llamadas a ese método?

Sergio Belmar:

¿Hay alguna forma de desactivar (por lo menos para hacer la comparativa) el gestor de seguridad para los plugins de Liferay?

Sí, puedes probar en cuanto mejora el rendimiento estableciendo la propiedad
portal.security.manager.strategy=none

[Sergio Sánchez, modificado hace 10 años.]

Ya está disponible la versión 6.1 CE GA3: http://www.liferay.com/es/community/releases/-/asset_publisher/nSr2/content/id/18245050

Incluye numerosas mejoras en lo relativo a PACL por lo que, podríais probarla y mantener el gestor de seguridad activo.

Un saludo.

[Sergio Belmar, modificado hace 10 años.]

Sergio Sánchez:

Ya está disponible la versión 6.1 CE GA3: http://www.liferay.com/es/community/releases/-/asset_publisher/nSr2/content/id/18245050

Incluye numerosas mejoras en lo relativo a PACL por lo que, podríais probarla y mantener el gestor de seguridad activo.

Un saludo.

Gracias por avisar Sergio, crearé un clon y actualizaré a la version GA3, espero que todos los ficheros de confguración sean compatibles.

Cualquier mejora que se os ocurra, será bienvenida.

Una cosa: ¿es razonable que el tamaño de la portada al hacer las pruebas con Jmeter sea de 130 KB? Si hago pruebas con una noticia, que pesa la mitad, obviamente va mucho más rápido...

Muchas gracias y un saludo.

[Sergio Belmar, modificado hace 10 años.]

Sergio Sánchez:

Sergio Belmar:

¿Es posible que haya muchas consultas del tipo "AssetEntryServiceImpl.incrementViewCounter" si ya tengo la propiedad asset.entry.increment.view.counter.enabled a false?

¿Reiniciaste el portal tras cambiar el valor en portal-ext.properties?
¿Se sigue observando llamadas a ese método?

Ya no aparecen estas consultas con la propiedad desactivada.

Sergio Belmar:

¿Hay alguna forma de desactivar (por lo menos para hacer la comparativa) el gestor de seguridad para los plugins de Liferay?

Sí, puedes probar en cuanto mejora el rendimiento estableciendo la propiedad
portal.security.manager.strategy=none

Si, después de preguntarte, localizé la propiedad: portal.security.manager.strategy=none

Con estos cambios y con algún otro más (desactivar filtros que aun tenia activos) parece que mejora un poco el rendimiento, una única petición se me queda en menos de 2 segundos.
Seguimos mirando la forma de optimizar un poco la página