Por qué un repositorio DSpace se vuelve lento

Factores técnicos que pueden afectar el rendimiento de DSpace: Solr, PostgreSQL, API REST, frontend, bots, caché y recursos de infraestructura.

Diagrama editorial sobre rendimiento de repositorios DSpace

Un repositorio DSpace puede sentirse lento por muchas razones. A veces el problema está en Solr, otras en PostgreSQL, en la API REST, en la interfaz Angular, en bots demasiado agresivos o en una infraestructura que quedó corta para el uso actual.

No conviene mirar solo un síntoma. Una página que demora en cargar puede esconder consultas lentas, índices desactualizados, demasiadas solicitudes concurrentes o archivos pesados servidos sin caché.

Solr y las búsquedas pesadas

DSpace usa Solr para búsquedas, facetas, navegación y estadísticas. Cuando el índice crece, una mala configuración puede impactar directamente en la experiencia de uso.

Señales habituales:

Búsquedas que responden tarde.
Facetas que demoran más que la página.
Filtros con demasiadas combinaciones.
Índices que no reflejan cambios recientes.
Alto consumo de memoria durante consultas.

El diagnóstico debe revisar tamaño de índices, consultas frecuentes, campos facetados, tareas de reindexación y comportamiento bajo carga.

PostgreSQL y consultas acumuladas

PostgreSQL sostiene buena parte de la operación de DSpace. Si la base de datos tiene consultas lentas, falta de mantenimiento o recursos insuficientes, el repositorio completo lo siente.

Algunos puntos a revisar son conexiones disponibles, tiempos de consulta, índices de base de datos, tareas de limpieza, tamaño de tablas, bloqueos y uso de disco.

No siempre se trata de “poner más servidor”. Muchas veces hay que entender qué consulta se repite, qué proceso la dispara y si la plataforma necesita mantenimiento o ajuste de configuración.

API REST y exceso de solicitudes

En DSpace 7 en adelante, la interfaz Angular conversa con el backend mediante API REST. Si una página genera demasiadas llamadas, el usuario percibe lentitud aunque el servidor no esté completamente saturado.

Esto puede ocurrir en páginas de colección, resultados de búsqueda, registros con muchos metadatos, estadísticas o componentes personalizados.

Conviene revisar la cantidad de solicitudes, respuestas repetidas, errores, tiempos de API y caché disponible entre frontend, backend y proxy.

Frontend Angular y renderizado

La interfaz Angular también puede ser parte del problema. Temas personalizados, componentes pesados, imágenes sin optimizar, exceso de scripts o errores en consola pueden aumentar tiempos de carga.

En instalaciones con SSR, además hay que revisar el proceso de renderizado del lado servidor, memoria disponible, logs, reinicios y tiempos de respuesta por ruta.

Una optimización seria debe mirar navegador y servidor al mismo tiempo.

Bots y crawlers

Los bots pueden generar mucha carga sin que existan más usuarios reales. Buscadores, cosechadores, bots de IA y rastreadores mal configurados pueden recorrer filtros, búsquedas, páginas repetidas o descargas de archivos.

El problema no es bloquear todo. Un repositorio necesita visibilidad e interoperabilidad. La clave es distinguir tráfico útil de tráfico abusivo, revisar logs y aplicar reglas por ruta, frecuencia y tipo de bot.

Caché y archivos pesados

CSS, JavaScript, imágenes y archivos públicos deberían servirse con una estrategia clara de caché. Si cada visita exige volver a pedir todo al servidor, la plataforma trabaja más de lo necesario.

También hay que revisar PDFs grandes, imágenes digitalizadas, descargas masivas y almacenamiento externo. En algunos casos, el cuello de botella está en transferencia o lectura de archivos, no en DSpace mismo.

Recursos e infraestructura

CPU, memoria, disco, red y número de procesos importan. Pero aumentar recursos sin diagnóstico puede esconder el problema por un tiempo y volverlo más caro.

Antes de crecer infraestructura, conviene medir: uso de CPU, memoria, I/O de disco, tiempos de base de datos, Solr, backend, frontend, proxy y tráfico automatizado.

Cómo abordar el diagnóstico

Un buen diagnóstico parte por evidencia:

Logs de aplicación, proxy y sistema operativo.
Métricas de CPU, memoria, disco y red.
Tiempos de PostgreSQL, Solr y API REST.
Rutas más solicitadas.
User-Agents e IPs con más actividad.
Errores 429, 502, 503 o 504.
Pruebas en horarios de baja y alta carga.

Con esa información es posible separar problemas de búsqueda, base de datos, frontend, bots, caché e infraestructura. Sin esa separación, cualquier ajuste queda a ciegas.

Evaluación técnica

¿Tu repositorio presenta problemas similares? Podemos realizar una evaluación técnica de DSpace para revisar arquitectura, PostgreSQL, Solr, API REST, frontend, bots, caché, respaldos y continuidad operativa.