Abres la lista de facturas y tienes que esperar diez segundos. Generas un informe y el navegador muestra una pantalla en blanco antes de cargar los datos. Lanzas una búsqueda de productos y todo se congela mientras la base de datos procesa las consultas. Si estas situaciones te suenan, tu instancia de Dolibarr sufre un problema de rendimiento. Y en más del ochenta por ciento de los casos, el culpable no es PHP ni el navegador, sino la base de datos MySQL o MariaDB que está detrás de tu ERP/CRM.
Una base de datos mal configurada transforma un Dolibarr reactivo en una herramienta que tus equipos terminan evitando. Vuelven a Excel, a notas manuscritas o a herramientas de terceros, y la promesa de un sistema de información unificado se desmorona. La buena noticia es que la gran mayoría de los problemas de lentitud provienen de causas conocidas, identificables y corregibles. En esta guía, NEXT GESTION comparte cinco trucos técnicos comprobados en cientos de instancias de Dolibarr en producción, desde un comerciante con diez usuarios hasta un industrial con varios cientos de conexiones simultáneas. Estos trucos cubren la configuración del motor, los índices, el mantenimiento, las cachés y la arquitectura del servidor. Aplicados correctamente, pueden dividir entre tres, cinco o incluso diez los tiempos de respuesta de tu aplicación.
Índice
- Por qué Dolibarr se ralentiza con el tiempo: comprender las causas
- Diagnóstico previo: medir antes de optimizar
- Truco n°1: optimizar la configuración MySQL/MariaDB
- Truco n°2: trabajar los índices y la estructura de las tablas
- Truco n°3: mantenimiento regular de la base de datos
- Truco n°4: activar y configurar las cachés aplicativas
- Truco n°5: adaptar la arquitectura del servidor a la carga
- Optimizaciones específicas de Dolibarr
- Vigilancia y monitoreo continuo
- Errores clásicos que hay que evitar
- Casos prácticos concretos
- ¿Cuándo llamar a un experto?
- FAQ: preguntas frecuentes sobre el rendimiento de Dolibarr
1. Por qué Dolibarr se ralentiza con el tiempo: comprender las causas
Cuando empiezas con Dolibarr, la aplicación es rápida. Todo va fluido, las páginas se muestran al instante y la experiencia de usuario es agradable. Seis meses, un año o dos años después, la misma aplicación tarda cinco, diez o veinte segundos en mostrar la misma lista. ¿Qué ha pasado?
Se acumulan varios fenómenos. En primer lugar, el volumen de datos aumenta: facturas, propuestas comerciales, pedidos, movimientos de stock, asientos contables, correos archivados, archivos adjuntos. Una tabla que contenía diez mil líneas tiene ahora quinientas mil, y algunas consultas mal escritas pasan de un milisegundo a dos segundos. Después, el número de usuarios simultáneos progresa con el crecimiento de la empresa, multiplicando las conexiones concurrentes y los bloqueos en las tablas. Los módulos complementarios instalados a lo largo del tiempo añaden sus propias consultas y tablas. Los índices inicialmente presentes ya no bastan para los nuevos usos. La caché aplicativa no está activada o está mal dimensionada. Por último, la configuración MySQL entregada por defecto en tu hosting, diseñada para funcionar en un servidor de un gigabyte de memoria, nunca se ha ajustado a la realidad de tu infraestructura.
Comprender estos mecanismos es esencial antes de actuar. El rendimiento no es un estado estático sino un equilibrio dinámico entre el volumen de datos, la carga de usuarios, la calidad del código, los índices disponibles y los recursos hardware asignados. Una optimización eficaz actúa sobre varios de estos ejes simultáneamente, y eso es precisamente lo que vamos a detallar en los cinco trucos siguientes.
2. Diagnóstico previo: medir antes de optimizar
La regla de oro de toda optimización es simple: no se optimiza lo que no se mide. Antes de modificar la más mínima línea de configuración, tómate el tiempo de establecer un diagnóstico cuantificado y reproducible de tu situación actual. Sin baseline, serás incapaz de saber si tus modificaciones han aportado una ganancia real o si simplemente has desplazado el problema.
Comienza identificando las páginas más lentas desde el punto de vista del usuario. Las herramientas de desarrollo integradas en tu navegador, accesibles con la tecla F12, muestran el tiempo de carga completo de cada página, el tiempo gastado en el servidor y el tiempo de renderizado del lado del cliente. Anota estas mediciones para cinco a diez acciones críticas de tu día a día: apertura de la lista de facturas, búsqueda de cliente, generación de un informe, validación de un pedido, acceso a la ficha de un producto con sus stocks. Estas cifras constituyen tu punto de referencia.
Activa después el registro de consultas lentas del lado MySQL o MariaDB, fijando un umbral bajo, por ejemplo un segundo. Este registro captura todas las consultas que superan ese plazo y revela inmediatamente los cuellos de botella. Combinado con una herramienta de análisis como pt-query-digest o mysqldumpslow, clasifica las consultas por tiempo acumulado, frecuencia y tiempo medio, indicándote exactamente dónde concentrar tus esfuerzos. Examina también las estadísticas globales del servidor: ratio de hit de la caché InnoDB, ratio de conexiones abandonadas, consultas en espera de bloqueo, tablas temporales escritas en disco. Estos indicadores orientan inmediatamente el diagnóstico.
Del lado Dolibarr, activa el modo debug en la configuración y consulta el registro aplicativo para identificar los módulos o hooks que añaden tiempo a cada página. Mide el tamaño de tu base de datos, el tamaño de cada tabla principal y el número de líneas contenidas. Una tabla de logs que pesa varios gigabytes o una tabla de eventos que contiene varios millones de líneas es una señal de alerta inmediata. Una vez trazado este panorama, sabes dónde estás y puedes abordar las optimizaciones con pleno conocimiento de causa.
3. Truco n°1: optimizar la configuración MySQL/MariaDB
La configuración por defecto de MySQL o MariaDB es una de las palancas más rápidas y más rentables para ganar en rendimiento. Es deliberadamente conservadora, prevista para funcionar en un servidor modesto sin riesgo de saturación de memoria. En un servidor dedicado a Dolibarr con ocho, dieciséis o treinta y dos gigabytes de RAM, esta configuración deja literalmente el noventa por ciento de los recursos sin utilizar.
El parámetro más impactante es sin duda el tamaño del buffer InnoDB. InnoDB es el motor de almacenamiento utilizado por todas las tablas Dolibarr modernas, y su buffer es la zona de memoria en la que MySQL almacena en caché las páginas de datos e índices. Cuanto más grande sea este buffer, menos necesitará el servidor leer del disco, y más rápidas serán las consultas. La regla generalmente admitida consiste en asignar entre el setenta y el ochenta por ciento de la RAM total del servidor a este buffer si la máquina está dedicada a la base de datos. En un servidor compartido que también aloja PHP y el servidor web, se bajará al cincuenta o sesenta por ciento, velando por dejar memoria suficiente al resto del sistema.
Otros parámetros merecen un ajuste atento. El tamaño del log InnoDB influye directamente en el rendimiento de escritura: un log demasiado pequeño provoca flushes demasiado frecuentes y ralentiza las inserciones masivas. El número máximo de conexiones debe reflejar la realidad de tu carga sin ser desmesurado, ya que cada conexión consume memoria. El buffer de ordenación, el buffer de join y la caché de tablas temporales deben adaptarse a tus consultas más complejas, sin estar tan sobredimensionados como para saturar la RAM en pico de carga. El modo de flush de las transacciones InnoDB puede ajustarse según tu tolerancia al riesgo: el valor más seguro garantiza la durabilidad de cada transacción al precio de escrituras de disco más numerosas, mientras que un valor intermedio ofrece un excelente compromiso para la mayoría de las pymes.
Por último, no olvides el motor de caché de consultas, ahora desactivado por defecto en las versiones recientes de MariaDB y directamente eliminado en MySQL. Si todavía estás en una versión antigua con esta caché activada y tu carga es mayoritariamente de escritura, paradójicamente puede ralentizar la aplicación. Una auditoría de configuración permite determinar con precisión qué debe activarse, ajustarse o desactivarse. NEXT GESTION practica este ejercicio sistemáticamente durante sus intervenciones y proporciona archivos de configuración adaptados a cada tamaño de instancia.
4. Truco n°2: trabajar los índices y la estructura de las tablas
Si la configuración del motor es la palanca más rápida, los índices son la palanca más potente. Un índice bien colocado puede transformar una consulta de cinco segundos en una consulta de un milisegundo. Por el contrario, un índice ausente en una columna frecuentemente filtrada obliga a la base a recorrer la totalidad de la tabla, operación cuyo coste explota a medida que los datos crecen.
Dolibarr se entrega con un conjunto razonable de índices que cubren los usos estándar. Sin embargo, en cuanto añades módulos de terceros, campos personalizados o extensiones desarrolladas a medida, estos índices pueden volverse insuficientes. Una búsqueda por referencia interna en la tabla de productos, un filtro por estado en la tabla de facturas combinado con una ordenación por fecha, una unión entre dos tablas hijas de un módulo adicional: tantos escenarios donde un índice complementario marca la diferencia entre una experiencia fluida y una experiencia laboriosa.
La identificación de los índices ausentes se hace a partir del registro de consultas lentas y de la herramienta EXPLAIN integrada en MySQL. EXPLAIN detalla la estrategia de ejecución elegida por el motor para cada consulta: uso de un índice, lectura secuencial completa, join anidado, tabla temporal en memoria o en disco. Una consulta que muestra la palabra ALL en la columna type o varios millones de líneas escaneadas es un candidato evidente a la optimización. La creación de un índice dirigido, a veces compuesto sobre varias columnas en el orden correcto, basta entonces para corregir el problema.
Atención sin embargo a no caer en el exceso. Cada índice tiene un coste en escritura: en cada inserción, actualización o eliminación, MySQL debe actualizar los índices afectados. Añadir diez índices a una tabla muy solicitada en escritura puede degradar el rendimiento global. La buena práctica consiste en indexar lo que realmente se utiliza, eliminar los índices redundantes o no utilizados, y privilegiar los índices compuestos bien pensados antes que una multiplicación de índices simples. Del lado de la estructura, verifica también que tus columnas usen los tipos correctos: un VARCHAR generosamente dimensionado consume más memoria de ordenación que un VARCHAR ajustado, un TEXT donde un VARCHAR bastaría impide ciertas optimizaciones, un tipo DATE es siempre más rápido que una fecha almacenada como cadena. Una auditoría de esquema por un experto Dolibarr permite detectar estos puntos de mejora a menudo invisibles desde la interfaz.
5. Truco n°3: mantenimiento regular de la base de datos
Una base de datos es un organismo vivo. Las inserciones, actualizaciones y eliminaciones sucesivas fragmentan las páginas, hacen que los índices se hinchen más allá de su tamaño óptimo, desincronizan las estadísticas utilizadas por el optimizador de consultas y acumulan datos obsoletos que nadie consulta ya. Sin mantenimiento regular, estos fenómenos terminan por degradar sensiblemente el rendimiento, incluso sin ninguna nueva actividad de negocio.
La primera operación de mantenimiento es la desfragmentación de las tablas. En InnoDB, esta operación se realiza mediante un comando que reconstruye la tabla y sus índices recuperando el espacio libre, reorganizando las páginas y reajustando el tamaño del archivo de datos. Realizada trimestralmente sobre las tablas principales, limita la expansión artificial de la base y preserva la localidad de los datos, es decir, la proximidad física de las líneas frecuentemente leídas juntas. Las tablas muy solicitadas en escritura, como la tabla de asientos contables, la tabla de journals o la tabla de stocks, se benefician particularmente de esta desfragmentación.
La segunda operación es la actualización de las estadísticas. El optimizador de MySQL elige su plan de ejecución basándose en estadísticas que estiman la cardinalidad de los índices y la distribución de los valores. Si estas estadísticas están obsoletas, el optimizador puede tomar decisiones absurdas, por ejemplo negarse a usar un índice perfectamente adaptado porque cree que la tabla todavía contiene mil líneas cuando ahora tiene un millón. El comando de actualización de estadísticas, ejecutado periódicamente, garantiza que los planes de ejecución sigan siendo pertinentes.
La tercera operación es el archivado y la purga de los datos obsoletos. Logs aplicativos, sesiones expiradas, adjuntos de correos de hace cinco años, documentos intermedios no validados, informes generados al vuelo: tantos datos que ocupan espacio sin valor de negocio real. Una política de retención clara, documentada y automatizada permite mantener el volumen bajo control. En algunas bases que NEXT GESTION ha auditado, más del sesenta por ciento del volumen estaba dedicado a datos que ningún usuario había consultado en años. Una simple purga con archivado offline permitió dividir entre tres el tamaño de la base y acelerar mecánicamente todas las operaciones.
Por último, no olvides la verificación de integridad. Una corrupción silenciosa, incluso menor, en una tabla crítica puede generar comportamientos aberrantes difíciles de diagnosticar. Una verificación mensual de las tablas principales y un seguimiento de los registros de errores MySQL previenen los incidentes antes de que se vuelvan visibles del lado del usuario.
6. Truco n°4: activar y configurar las cachés aplicativas
La mejor consulta es la que no se ejecuta. Esta máxima resume perfectamente la lógica de la caché: conservar en memoria el resultado de operaciones costosas para servirlas instantáneamente en las consultas siguientes. Dolibarr y su ecosistema PHP ofrecen varios niveles de caché que, correctamente configurados, pueden reducir drásticamente la carga sobre la base de datos.
La primera caché que hay que activar es el opcache de PHP. Sin opcache, PHP relee, parsea y compila cada archivo fuente en cada solicitud, consumiendo CPU y tiempo de manera significativa. Con opcache activado, el bytecode compilado se conserva en memoria y se reutiliza, lo que puede dividir entre dos el tiempo de respuesta global de la aplicación. La configuración consiste en asignar memoria suficiente para almacenar todos los archivos de Dolibarr, autorizar un número de archivos coherente con el tamaño de tu instalación y ajustar los parámetros de validación para evitar verificaciones inútiles en producción. Es una optimización simple, gratuita y de ganancia casi sistemáticamente espectacular.
El segundo nivel concierne a la caché aplicativa de Dolibarr mismo. Varias zonas de la aplicación pueden ponerse en caché: listas de países, divisas, tipos de pago, derechos de usuario, parámetros de configuración global, traducciones. Estos datos se leen en casi cada página pero cambian muy raramente. Conservarlos en memoria evita decenas, incluso cientos de consultas redundantes en cada carga. Según los módulos instalados y la versión utilizada, estas cachés pueden activarse mediante parámetros avanzados o extensiones dedicadas.
Para instancias de mayor carga, es pertinente ir más lejos con una caché externa compartida entre los procesos PHP. Soluciones como Redis o Memcached permiten poner en caché resultados de consultas complejas, sesiones de usuario u objetos de negocio reconstituidos. La ganancia es particularmente notable en cuadros de mando, agregaciones de cifras y páginas cargadas a la vez por numerosos usuarios. La puesta en marcha exige una configuración cuidada, una estrategia de invalidación rigurosa y una supervisión activa para garantizar la coherencia de los datos mostrados. Es típicamente una intervención que NEXT GESTION acompaña de extremo a extremo en las instancias Dolibarr más exigentes.
No olvidemos la caché del navegador y la caché HTTP. Los recursos estáticos de Dolibarr, como hojas de estilo, scripts JavaScript e imágenes, deben servirse con cabeceras de caché apropiadas para evitar que se vuelvan a descargar en cada página. Una configuración cuidada del servidor web, completada eventualmente por un CDN para los despliegues multi-sitio, aligera la carga de red y mejora la percepción de rapidez del lado del usuario.
7. Truco n°5: adaptar la arquitectura del servidor a la carga
Todas las optimizaciones de software del mundo no pueden compensar un servidor subdimensionado o una arquitectura inadecuada. A partir de cierto volumen de datos, usuarios simultáneos o integraciones conectadas, se hace necesario revisar el cimiento material sobre el que reposa tu Dolibarr.
El primer parámetro a examinar es la memoria RAM disponible. Una base de datos de alto rendimiento necesita RAM en abundancia, principalmente para el buffer InnoDB evocado más arriba. La regla empírica consiste en apuntar a una RAM total al menos igual al tamaño de la parte activa de tu base, es decir, las tablas e índices que consultas regularmente. Un servidor de ocho gigabytes para una base de quince gigabytes activa pasará la mitad de su tiempo leyendo del disco, sea cual sea tu tuning. Aumentar la RAM es a menudo la inversión hardware más rentable.
El segundo parámetro es el subsistema de almacenamiento. El paso de un disco mecánico a un SSD divide generalmente entre diez las latencias de lectura aleatoria, lo que transforma la experiencia del usuario en consultas complejas. El paso de un SSD SATA a un SSD NVMe aporta una ganancia adicional significativa en cargas intensivas en escritura. En los hostings virtualizados, verifica la clase de almacenamiento propuesta y no dudes en subir de gama si tus mediciones señalan un cuello de botella en disco.
El tercer parámetro concierne a la CPU. Dolibarr y su motor PHP son sensibles a la frecuencia de reloj, aún más que al número de núcleos, para las consultas individuales. En cambio, en las cargas multi-usuario, el número de núcleos se vuelve determinante para absorber las consultas en paralelo. Una auditoría de la carga media, los picos y la naturaleza de las operaciones permite elegir la combinación correcta.
Más allá del dimensionamiento vertical de una sola máquina, existen arquitecturas más avanzadas para las instancias muy solicitadas. La separación del servidor web y del servidor de base de datos en dos máquinas distintas reparte la carga y evita los conflictos de recursos. La puesta en marcha de una replicación primario-secundario permite descargar las consultas de lectura pesadas hacia una réplica conservando las escrituras en el servidor principal. El uso de un proxy de conexión para mutualizar las conexiones PHP del lado MySQL reduce la carga en pico. Estas arquitecturas se justifican a partir de cierto umbral de criticidad o de volumetría y se inscriben en una reflexión global sobre la alta disponibilidad que NEXT GESTION conduce con sus clientes ETI y grandes cuentas.
Por último, la red juega un papel a menudo subestimado. Una latencia excesiva entre el navegador del usuario, el servidor web y el servidor de base de datos degrada considerablemente la experiencia, sobre todo en las páginas que multiplican los intercambios. Un hosting situado en proximidad geográfica de tus usuarios principales y una red interna de baja latencia entre los diferentes ladrillos de la arquitectura marcan a menudo la diferencia en los workflows de negocio intensivos.
8. Optimizaciones específicas de Dolibarr
Más allá del motor de base de datos y de la arquitectura, Dolibarr mismo ofrece varias palancas de optimización. La desactivación de los módulos no utilizados es probablemente la más simple y la más eficaz. Cada módulo activado carga sus propias bibliotecas, ejecuta sus hooks en cada página y consume recursos incluso si no lo utilizas. Hacer la criba de los módulos realmente necesarios reduce el número de consultas por página y acelera la carga global.
La gestión de los campos personalizados merece también una atención particular. Un campo personalizado mal concebido, por ejemplo una lista desplegable alimentada por una consulta pesada sin caché, puede ralentizar significativamente cada apertura de ficha. Privilegia los campos dirigidos, las listas estáticas cuando es posible y las consultas optimizadas con índices apropiados.
Las exportaciones masivas y los informes pesados deben pensarse en términos de impacto sobre el sistema. Una exportación de cien mil líneas lanzada en pleno día por un usuario puede paralizar la aplicación para todos los demás. La puesta en marcha de colas de espera, planificación nocturna o generación en segundo plano permite aislar estas operaciones sin impactar la experiencia interactiva.
Del lado de la interfaz, algunas listas muestran por defecto informaciones agregadas costosas de calcular, como el total de las facturas en curso o el stock valorizado de un producto. Cuando estas informaciones no son críticas para el uso cotidiano, su desactivación o su cálculo a demanda aligera el renderizado de cada línea y acelera la navegación. NEXT GESTION acompaña a sus clientes en la personalización fina de estas visualizaciones para alinear el rendimiento con las verdaderas necesidades de negocio.
9. Vigilancia y monitoreo continuo
Optimizar una vez no basta. Una instancia Dolibarr evoluciona constantemente: nuevos usuarios, nuevos módulos, nuevos datos, nuevos usos. Sin vigilancia continua, las ganancias arduamente adquiridas se degradan insidiosamente. Poner en marcha un monitoreo permanente es por tanto una etapa indispensable de todo enfoque de rendimiento duradero.
El monitoreo cubre varios ejes. A nivel de sistema, se sigue la utilización de CPU, la memoria libre, la latencia y el caudal de almacenamiento, la carga media y el número de procesos activos. A nivel de base de datos, se vigilan el ratio de hit del buffer InnoDB, el número de consultas lentas por minuto, las conexiones activas, los bloqueos en espera y el tamaño de las tablas principales. A nivel aplicativo, se instrumentan las páginas más usadas para medir su tiempo de respuesta y detectar las regresiones.
Estas métricas deben recogerse en una herramienta centralizada que permita visualizar las tendencias en el tiempo, definir alertas al sobrepasar umbrales y correlacionar los eventos. Herramientas open source como Prometheus con Grafana, o soluciones todo-en-uno como Zabbix u ofertas SaaS dedicadas, permiten poner en marcha este dispositivo sin inversión desmesurada. Un cuadro de mando claro, consultado semanalmente, da una visión de conjunto de la salud de la plataforma y orienta las acciones correctivas.
El seguimiento de los incidentes completa la fotografía. Cada ralentización señalada por un usuario debe registrarse, fecharse, ponerse en relación con las métricas del sistema del momento y analizarse. Con el tiempo, emergen patrones: el lunes por la mañana siempre satura, el fin de mes carga la contabilidad, ciertos usuarios desencadenan operaciones atípicas. Este conocimiento fino del comportamiento real de tu instancia es precioso para anticipar antes que sufrir.
10. Errores clásicos que hay que evitar
En la urgencia de un problema de rendimiento, ciertos intentos bien intencionados hacen más mal que bien. El primer error consiste en modificar varios parámetros a la vez sin medir el impacto de cada cambio. Si la situación mejora, no sabrás cuál ha funcionado. Si se degrada, serás incapaz de volver atrás con precisión. Toda modificación debe ser aislada, medida y validada antes de pasar a la siguiente.
El segundo error es copiar y pegar una configuración MySQL encontrada en un blog sin comprenderla. Una configuración optimizada para un servidor web de alto tráfico no tiene nada que ver con una configuración adaptada a un ERP transaccional. Un archivo de parámetros mal comprendido puede multiplicar los bugs, saturar la RAM o incluso impedir el arranque del servicio.
El tercer error es sobreindexar. Frente a consultas lentas, la tentación es añadir un índice en cada columna mencionada en un WHERE. Raramente es la respuesta correcta. Un índice bien pensado vale más que diez índices redundantes, y cada índice añadido penaliza las escrituras.
El cuarto error es ignorar las copias de seguridad antes de la intervención. Una optimización, sobre todo en los índices o la estructura de las tablas, debe ir precedida de una copia de seguridad completa, verificada y restaurable. Trabajar sin red en una base de producción es un riesgo que nadie debería correr.
Por último, el quinto error es subestimar el efecto de aprendizaje. Una optimización produce su pleno efecto una vez que las cachés están calientes, las estadísticas están al día y los usuarios han recuperado sus hábitos. Medir el impacto en la primera hora puede dar una imagen engañosa. Deja que funcione varios días antes de sacar conclusiones definitivas.
11. Casos prácticos concretos
Para anclar estos principios en la realidad, aquí van tres ejemplos extraídos de las intervenciones de NEXT GESTION, anonimizados pero fieles a las situaciones encontradas.
Primer caso, un comerciante de material profesional que utiliza Dolibarr desde hace cinco años, con una base de doce gigabytes y aproximadamente veinticinco usuarios simultáneos. El diagnóstico revela un buffer InnoDB de ciento veintiocho megabytes, es decir el valor por defecto, en un servidor que dispone de dieciséis gigabytes de RAM. Primera intervención: ajuste de la configuración MySQL con el buffer llevado a diez gigabytes. Resultado inmediato, tiempos de respuesta divididos entre tres en el conjunto de las pantallas. Segunda intervención: análisis del registro de consultas lentas y creación de cuatro índices complementarios sobre campos personalizados muy utilizados. Resultado, los informes pasan de doce segundos a menos de dos. Tercera intervención: purga de ocho años de logs aplicativos y de adjuntos huérfanos. Resultado, base reducida a cinco gigabytes y copias de seguridad dos veces más rápidas.
Segundo caso, una pyme industrial que gestiona su MRP con Dolibarr y varios módulos complementarios. Los cálculos de necesidades tomaban más de cuarenta minutos en pleno día y bloqueaban la aplicación. El diagnóstico identifica una combinación de consultas mal optimizadas, ausencia de índices adaptados sobre las tablas de explosión de las listas de materiales y opcache desactivado. Tras refundir las consultas críticas, añadir cinco índices dirigidos y activar opcache, el cálculo global cae a cuatro minutos y puede lanzarse sin molestar a los usuarios.
Tercer caso, un mayorista e-commerce con un Dolibarr conectado a una tienda en línea por un conector que sincroniza permanentemente stocks y pedidos. Bajo carga, la aplicación se volvía inutilizable. Diagnóstico: arquitectura mono-servidor saturada, ausencia de caché externa, consultas repetitivas sobre datos poco variables. Puesta en marcha de una separación del servidor web y de la base de datos, adición de una caché Redis para las listas de referenciales y optimización de las consultas del conector. Resultado, una plataforma estable incluso en plena campaña comercial, con tiempos de respuesta divididos entre cinco.
12. ¿Cuándo llamar a un experto?
Muchas optimizaciones están al alcance de un administrador de sistemas o de un integrador Dolibarr experimentado. Los ajustes de configuración, la activación de opcache, la puesta en marcha de un monitoreo de base, la limpieza de los datos obsoletos pueden conducirse internamente con un poco de método y prudencia.
Sin embargo, ciertas situaciones justifican la intervención de un experto. Si tus mediciones no convergen hacia una causa clara, si las optimizaciones habituales no producen las ganancias esperadas, si tu instancia combina varios módulos complejos o supera las volumetrías corrientes, la experiencia acumulada de un especialista marca la diferencia. Una auditoría en profundidad identifica puntos que un ojo no entrenado puede pasar por alto: un esquema de datos no óptimo, una consulta PHP que genera cientos de subconsultas, un módulo de terceros que consume recursos desproporcionados, una configuración de sistema incompatible con la carga real.
NEXT GESTION acompaña a sus clientes en todas las etapas de este enfoque. Auditoría de rendimiento documentada, plan de optimización cuantificado, puesta en marcha de las correcciones, formación de los equipos internos en monitoreo y tuning continuo, contratos de mantenimiento proactivo. Nuestro método se basa en la medición, la transparencia y la transmisión de competencias para que tus equipos sigan siendo autónomos tras nuestra intervención. Si tu Dolibarr se ralentiza y quieres tenerlo claro, contáctanos para un diagnóstico preliminar.
13. FAQ: preguntas frecuentes sobre el rendimiento de Dolibarr
Mi Dolibarr es lento solo en algunas páginas, ¿hay que optimizar igualmente todo el servidor? No. Una lentitud dirigida apunta casi siempre hacia un problema específico: consulta mal escrita, índice ausente, módulo particular, cálculo costoso. El análisis del registro de consultas lentas y el uso de EXPLAIN bastan a menudo para identificar la causa. Una optimización global del servidor vendrá en un segundo momento si el diagnóstico lo justifica.
¿Cuánto dura una auditoría de rendimiento completa? Para una instancia de pyme estándar, una auditoría completa que incluye configuración MySQL, índices, consultas, arquitectura y código aplicativo requiere entre dos y cinco días según la complejidad. Las conclusiones se entregan en un informe detallado acompañado de un plan de acción priorizado.
¿Hay que actualizar Dolibarr para ganar en rendimiento? A menudo sí. Cada versión mayor aporta su lote de optimizaciones sobre las consultas más críticas, índices adicionales y a veces una refundición de módulos completos. Migrar de una versión antigua a una versión reciente aporta generalmente una ganancia medible, en complemento de las otras palancas de optimización.
¿Un hosting compartido puede hacer funcionar Dolibarr correctamente? Para una estructura muy pequeña con pocos usuarios y pocos datos, sí. Más allá, los límites de los hostings compartidos sobre la memoria MySQL, los procesos PHP y la latencia disco se vuelven prohibitivos. Un VPS dedicado, incluso modesto, ofrece una relación calidad-precio mucho mejor en cuanto se franquea el umbral de algunos cientos de facturas al mes.
¿El rendimiento depende del número de usuarios o del tamaño de la base? De ambos, pero de manera diferente. El tamaño de la base afecta a la duración de las consultas individuales y a la presión sobre el buffer InnoDB. El número de usuarios simultáneos afecta a la concurrencia sobre los bloqueos, el consumo de CPU y la memoria de los procesos PHP. Una optimización eficaz tiene en cuenta estas dos dimensiones.
¿Hay que purgar regularmente los datos antiguos? Sí, a condición de respetar las obligaciones legales de conservación. Documentos contables, facturas, declaraciones deben conservarse según las duraciones legales aplicables. En cambio, los logs técnicos, las sesiones, los archivos temporales y los adjuntos obsoletos pueden archivarse o purgarse sin riesgo, con una ganancia de rendimiento notable.
¿El paso a PostgreSQL aportaría una ganancia? PostgreSQL es un excelente motor de base de datos y Dolibarr puede funcionar sobre PostgreSQL. La ganancia pura en rendimiento no es sistemática: MySQL/MariaDB bien configurado sigue siendo muy eficiente para el perfil de carga de Dolibarr. La elección depende más de la estrategia de infraestructura y de las competencias disponibles que de una ventaja de rendimiento evidente.
Mis copias de seguridad ralentizan toda la aplicación, ¿qué hacer? Una copia de seguridad mal concebida bloquea las tablas y bloquea a los usuarios. Privilegia las herramientas que hacen copias de seguridad en caliente sin bloquear, planifica las copias completas fuera de las horas laborables, usa la replicación para descargar las copias hacia una réplica. Una estrategia de copia de seguridad optimizada preserva tanto la seguridad como el rendimiento.
Artículo redactado por NEXT GESTION, experto Dolibarr y acompañamiento de las empresas en la optimización, la securización y la evolución de su ERP/CRM. ¿Quieres auditar el rendimiento de tu instancia Dolibarr? Contacta a nuestros consultores: contact@nextgestion.com.