grommunio mejora el rendimiento del buzón

Ya está incluido en la versión de la comunidad y pronto será empaquetado y estará disponible para todos los clientes de grommunio: Gracias a un cambio en la forma en que grommunio maneja las bases de datos de buzones de correo electrónico, los equipos se beneficiarán de una mejora significativa en el rendimiento de los buzones.

El problema es complejo, pero generalizado: En el pasado, podía ocurrir que los usuarios experimentaran tiempos de espera más largos cuando muchos clientes accedían a buzones individuales al mismo tiempo, por ejemplo cuando varios usuarios realizaban consultas de búsqueda más largas en un buzón al mismo tiempo, como cuando se preparaba una reunión. La razón es el deseo de coherencia de los datos: sólo un cliente a la vez puede acceder a los datos de un buzón y hacer cambios, tras lo cual es el turno del siguiente cliente; de lo contrario, hay riesgo de incoherencias. Este acceso “en serie” (es decir, uno tras otro) puede llevar mucho tiempo, sobre todo con grandes conjuntos de datos (y numerosos clientes que quieran acceder al mismo tiempo). El problema no se limita a grommunio, sino que se aplica en principio a todos los servicios web y de correo: Si quieres datos consistentes, tienes que procesar los accesos uno tras otro; si quieres alto rendimiento, tienes que paralelizar los accesos. Pero hay soluciones inteligentes que pueden ayudar con este dilema. grommunio ha implementado una de ellas y ha conseguido así un importante aumento del rendimiento.

Escritura y sólo lectura: ¿en serie o en paralelo?

La solución al problema: se distingue entre acceso de sólo escritura y de sólo lectura. El acceso de sólo lectura (por ejemplo, de un cliente de correo que actualiza una carpeta compartida) puede ser permitido por el servidor en paralelo por varios clientes al mismo tiempo, y también es posible el almacenamiento en caché. Sólo se requiere una “única fuente de verdad” para la escritura, es decir, el acceso exclusivo de un cliente; de lo contrario, podrían producirse datos incoherentes o un cliente podría sobrescribir los cambios realizados por otro.

Implementar esto técnicamente requiere algún conocimiento de cómo funciona grommunio (o cualquier otro servidor de correo y base de datos). En grommunio hay una base de datos central MySQL para los metadatos y cachés para los metadatos del usuario, es decir, una gran tabla con todos los datos, incluyendo, por ejemplo, la tabla de contenidos para la información sobre los usuarios y la asignación de donde exactamente se puede encontrar el buzón de un usuario.

También hay una base de datos SQLite para cada usuario, que contiene los datos específicos del usuario, incluidos todos los correos electrónicos. Para el usuario individual, también es el componente central del buzón, pero también puede ser un cuello de botella si llegan numerosas peticiones al mismo tiempo. No obstante, el sistema es flexible y ha demostrado su eficacia, puede ampliarse según las necesidades y es una parte importante del alto rendimiento del buzón de grommunio.

Sin embargo, si un cliente realiza una búsqueda en un buzón más grande, por ejemplo, éste se bloquea para otras peticiones hasta que la petición de búsqueda se haya procesado por completo. En el lado del servidor, esto se implementa a través de un Mutex, otros clientes tienen que esperar y, en el peor de los casos, se encuentran con un tiempo de espera - lo que significa un mensaje de error para el usuario.

flujo de acceso al buzón - servidor típico](/img/posts/24-06-19_Mailbox-Access-Flow-typical_server.png)

Problema con el mutex del servidor exmdb típico: El hilo 1 bloquea el mutex y trabaja con el recurso compartido, mientras que el hilo 2 está bloqueado por el mutex y tiene que esperar.

Mayor rendimiento del buzón gracias a un servidor de gestión que toma decisiones situacionales

Debido a que el Mutex realmente no tiene sentido para consultas de búsqueda o accesos similares de sólo lectura, ya que la base de datos no se modifica, los desarrolladores de grommunio han implementado una solución que elimina este cuello de botella. Los desarrolladores han adaptado el servidor de gestión (exmdb) para este propósito. Es complejo y ya ha coordinado el acceso con sus más de 120 funciones. Para incorporar la paralelización para el acceso de sólo lectura, los desarrolladores tuvieron que adaptar más de 18.000 líneas de código. Donde antes un Mutex por buzón evitaba conflictos pero también provocaba ocasionalmente congestiones, el nuevo sistema se las arregla sin un “gran” mutex, inspeccionando en su lugar cada petición y decidiendo según la situación si puede paralelizarse con seguridad.

flujo de acceso al buzón - servidor adaptado](/img/posts/24-06-19_Mailbox-Access-Flow-adapted_server.png)

Mejora con el servidor exmdb adaptado: Los hilos 1 y 2 reciben una respuesta más rápida del recurso compartido.

“Este enfoque demostró ser significativamente más rápido, más flexible y es perceptible para todos los equipos que trabajan con buzones compartidos, especialmente en el trabajo diario. Un ejemplo típico es la preparación conjunta de una reunión de equipo, en la que todos los participantes quieren ponerse al día rápidamente en las horas previas a la reunión. Pero eso es sólo un ejemplo, los usuarios nos hablan con entusiasmo de otras situaciones que ahora se han acelerado considerablemente gracias al cambio. ”, afirma el CTO de grommunio, Michael Kromer.

Más información sobre otras funciones de grommunio.