Este documento describe los componentes de la arquitectura de Alfresco Enterprise y dos escenarios típicos de solución: una plataforma para carga masiva de contenidos y una plataforma empresarial para colaboración. También analiza consideraciones de diseño y optimización para cada escenario, incluyendo el escalado vertical u horizontal de los diferentes componentes como el repositorio, Share, almacenamiento y base de datos.

1. Alfresco
Enterprise:
Escalabilidad
y
Tuning
Toni
de
la
Fuente
Senior
Solu/ons
Engineer
Spain
&
Portugal
toni.delafuente@alfresco.com

2. El webinar comenzará en
unos minutos.
Las líneas de voz de los
asistentes estarán
desactivadas. Use el área de
chat “Q&A” para hacer las
preguntas que
responderemos al finalizar la
sesión.
2

3. Contenidos
● Componentes
de
la
arquitectura
● Escenarios
de
soluciones
Alfresco
o Carga
masiva
de
contenidos
o Plataforma
combinada:
contenidos,
acciones,
usuarios
● Pruebas
de
carga
● Conclusiones
y
preguntas
3

4. Componentes
de
la
arquitectura
4

5. Componentes
1. Repositorio
Alfresco
2. Alfresco
Share
3. Aplicaciones
de
terceros
4. Base
de
datos
5. Content
Store
6. Índices
5

6. Escenarios
de
la
solución
6

7. Gestión completa de
contenidos
Ges/ón
de
Ges/ón
Colaboración
Ges/ón
de
Archivo
Contenidos
Documental
Expedientes
Email
Web
¿Interfaces?
¿Número
de
…?
¿Tipos
de
contenido?
Un
repositorio
construido
con
una
base
¿Cuantos
tecnológica
sólida
componentes?
7

8. ¿Lo mismo para todos?
8

9. Soluciones con Alfresco
según el uso
1. Plataforma
de
carga
masiva
• Alto
rendimiento
en
procesos
por
lotes,
5+
millones
de
documentos,
asequible
• Ej:
archivo
y
digitalización
masiva
2. Plataforma
empresarial
de
colaboración
● Uso
intenso
de
sistema
de
ficheros,
mezcla
entre
contenido
e
interfaz
● Ej:
Colaboración,
ges/ón
del
conocimiento,
contenidos
generados
por
los
usuarios
9

10. Los 3 procesos más
importantes
Arquitectura
(1)
Diseño Tuning
(2) (3)
10

11. Carga
masiva
de
contenidos
11

12. Requerimientos de Carga
masiva de contenidos
● 100-­‐1000
usuarios
(sólo
con
acceso
de
lectura)
● 10.000
documentos
cargados
por
día
durante
horas
nocturnas
● 20
millones
de
documentos
al
año
● Tipos
de
documentos:
PDF,
TIFF,
JPG
● Sólo
lectura,
sin
indexado
total,
modelo
de
contenido
básico
● Pocas
o
ninguna
reglas
o
acciones
● Sin
transformación
de
contenido
● Ges/ón
del
contenido
centralizado
● Interfaces:
aplicación
externa,
API
na/va,
WebScripts,
CMIS.
No
CIFS/WebDAV/FTP
o
Webclient
12

13. Consideraciones de
arquitectura
● Uso
de
CPU
y
memoria
intensivo
o Escalar
ver/calmente
en
lugar
de
horizontalmente
● Los
procesos
batch
son
la
CLAVE
o Atómicos
-­‐>
Escalar
ver/calmente,
+CPU
+Memoria
o Paralelos
-­‐>
Escalar
horizontalmente
con
2
Repositorios
en
cluser
compar/endo
un
mismo
almacenamiento.
● Escalar
(ver/cal
y
horizontalmente)
el
almacenamiento
o Caringo
CAStor
o Content
Store
Selector
o Escalar
y
op/mizar
la
BBDD
(Mysql
proxy
/
Oracle
RAC)
● Evitar
Sparc
T2000
series
(y
familia
similar)
13
o Bueno
para
proceso
paralelo
pero
pobre
en
operaciones
atómicas

14. Dos capas
14

15. Procesos batch paralelos
15

16. Buenas prácticas en diseño
● Optimiza los procesos batch
o API nativa
o Más de un documento por transacción
o Ejemplo: 150 crear, 50 borrar
● Distribuye el contenido
o Balancea el árbol de contenidos
o Puede servir multi-tenant? (batch paralelos e independientes)
● Consideraciones para cargas masivas
o Evita envíos a la papelera con cm:temporary
● Optimización de los índices
o DoNotIndex aspect 16

17. Buenas prácticas en
optimización
● Optimización de I/O Ejemplo de configuración JVM :
o Mejor elección: Discos Locales * -server –Xms6G –Xmx6G
o Latencia de red con la RDBMS -XX:PermSize=256m
-XX:MaxPermSize=256m
● Configuración a nivel ORM -XX:NewRatio=2
-XX:+UseParNewGC
o Tuning del “connection pool” -Xloggc:/tmp/gc.log
-verbose:gc
o Desabilitar la caché de consultas -XX:+PrintGCTimeStamps
durante la importación -XX:+PrintGCDetails
● Evita características innecesarias
o Auditoría / Quotas
o Check ACL (ejecuta como admin) / Reglas
o Subsystems (ej. VFS)
● Tuning de Lucene
17
o index.tracking.disableInTransactionIndexing=true
o mergeFactor

18. Plataforma
de
colaboración
18
18

19. Plataforma de colaboración
● 100-­‐10.000
usuarios
(lectura
y
escritura)
o Ges/ón
del
contenido
descentralizado
● 10.000-­‐1
millón
de
documentos
(o
incluso
10
millones
)
● 1000
actualizaciones
de
documentos
por
día
● Múl/ples
versiones
por
documento
o Tipos
de
documentos:
Office,
dibujo,
imágenes,
etc.
o Gran
uso
de
transformación
del
contenido
(PDF,
Flash,
thumbnail)
● Indexación
completa
de
todos
los
documentos
o Múl/ples
modelos
de
contenido
● Múl/ples
(avanzadas)
reglas
y
acciones
● ACL
dinámicas
(múl/ples
cambios
con/nuamente)
● Interfaces:
Todas.
Para
DM
principalmente
CIFS/WebDAV.
Para
colaboración
Share/Webclient.
Webscripts
para
aplicaciones
y/o
portlets
19

20. Consideraciones de
arquitectura
● Despliegue
total
de
la
plataforma
o Plataforma
de
DM/Colaboración
con
múl/ples
procesos
involucrados
o Global
(sin
ventanas
de
mantenimiento)
● Escalar
Share
horizontalmente
de
forma
independiente
al
repositorio
o Balanceo
de
carga
frontal
e
“intercapa”
o Separar
lectura
de
escritura
y
tareas
programadas
● Separar
el
servidor
de
transformaciones
o Servidor
independiente
o Daemon
Open
Office
● Escalado
horizontal
y
ver/cal
de
la
infraestructura
o Escalar
CIFS
con
DFS
o Todos
los
protocolos
basados
en
HTTP
escalan
de
forma
similar
(incluido
SPP/7070)
● Balancea
mul/-­‐CPU
(scale
up)
y
cluster
mul/-­‐nodo
(scale
out)
o Ojo
con
los
índices
20

21. Plataforma de contenidos
transparente
21

22. Buenas prácticas en diseño
● Distribuir
y
balancear
el
árbol
de
contenidos
FUNDAMENTAL!
o La
ges/ón
descentralizada
es
compleja
o Usa
conceptos
comunes
(espacios,
e/quetas,
categorías)
● Ojo
con
con
las
versiones
y
los
índices
o No
apliques
cm:versionable
a
todo
el
cm:content
o Usa
el
VersionCleaner
● Modelado
de
datos
o Mejor
aspectos
que
/pos
/
reu/lización
de
metadatos
o Opciones
de
indexado
de
los
contenidos
● Cuotas
y
usos
o Debemos
preveer
una
“explosión”
del
repositorio
22

23. Buenas prácticas en
optimización
● RDBMS
● No
dejes
la
configuración
por
defecto
-­‐-­‐>
RTFM
:)
● Configuración
de
la
capa
ORM
● L2
cache:
incremento
lineal
con
la
memoria
RAM
● Incrementa
el
connec/on
pool
y
connec/on
threads
con
la
RBDMS
(db.pool.max)
● Configuración
óp/ma
de
Alfresco
● VFS
thread
pool
(por
defecto:
<threadPool init="25" max="50"/>
)
● Op/miza
el
uso
de
ACLs
y
precarga
de
búsquedas
más
usadas
(si
es
necesario)
system.acl.maxPermissionCheckTimeMillis=10000
system.acl.maxPermissionChecks=1000
● Op/mización
de
Lucene
● lucene.maxAtomicTransformationTime=20
23
● lucene.indexer.mergeFactor

24. Pruebas
de
carga
24

25. Alfresco Benchmarks
● Alfresco
Benchmark
Tools
o alfresco-­‐bm
-­‐
hup://wiki.alfresco.com/wiki/Server_Benchmarks
o SimpleInjector
-­‐
(disponible
en
partners.alfresco.com
en
unos
días)
o JMeter
o CIFS
loading
● Resultados
sobre
pruebas
de
carga
con
Alfresco
o Unysis
benchmark
results
o JCR
Benchmarks
● WIP
o Documento
sobre
escalabilidad
para
partners.
o Más
información
para
+3.4
25

26. Controla tu solución
Alfresco
● Usa
el
modo
debug!
● Análisis
de
Alfresco
o JMX
(for
Enterprise
Only
see
Admin
Guide)
hup://wiki.alfresco.com/wiki/JMX
o Audit
Surf
hup://forge.alfresco.com/projects/auditsurf/
o Nagios
integra/on
hup://forge.alfresco.com/projects/nagios4alfresco/
● Análisis
de
la
Infraestructura
o VisualVM
(JVM)
hup://ur.ly/esjZ
o YourKit
(JVM)
hup://wiki.alfresco.com/wiki/JMX
o WireShark
(Network)
hup://www.wireshark.org/
o Mysql
Query
Profiler
(DBMS)
26
hup://dev.mysql.com/tech-­‐resources/ar/cles/using-­‐new-­‐query-­‐profiler.html

27. Conclusiones
y
preguntas
27
27

28. Escalar horizontalmente vs.
verticalmente
Pros
Contras
Mejora
el
rendimiento
en
Coste
de
procesadores
procesos
batch
Escalar
Ver/calmente
Mejora
el
rendimiento
en
las
Posible
coste
adicional
en
transformaciones
suscripciones
Mejora
el
rendimiento
en
Tiempo
para
sincronización
procesos
paralelos
de
los
índices
Escalar
Posible
coste
adicional
en
Alta
Disponibilidad
Horizontalmente
suscripciones
Separación
de
Lectura/
Necesita
balanceo/caching
Escritura
28

29. Las reglas de oro
● Elige
la
arquitectura
correcta
● Distribuye
la
carga
de
la
infraestructura
● Aprovecha
las
capas
para
caché
● Maximiza
el
uso
de
la
plataforma
● Ten
en
cuenta
el
rendimiento
de
tu
aplicación
durante
el
diseño
● Elige
la
API
correcta
● Desac/va
lo
que
no
u/lices
(ACLs,
indexado,
VFS,
etc.)
● Prueba
todo
en
la
fase
de
test.
● Prueba,
prueba,
prueba
● Realiza
las
pruebas
y
compártelas
con
Alfresco
Support
/
Solu/on
Engineering
29

30. Preguntas y Feedback
● ¿Alguna
pregunta?
● Comparte
las
experiencias
con
nosotros
(buenas
y
malas)
● Arquitecturas
escaladas
sa/sfactoriamente
● Limitaciones,
cuellos
de
botella
● Configuraciones
ú/les
=>
Implementación
=>
Resultados
● Qué
funciona
y
qué
no
funciona.
30

31. Gracias por asistir al webinar
Toni de la Fuente!
toni. delafuente@alfresco.com!
twitter: @toniblyx !
blog: http://blyx.com!
31