Este artículo es el segundo de una serie de dos, en los que se aborda de manera muy básica, los conceptos de ejecución multihilo y multiprocesador, así como sus implicaciones en la programación en general, y en el rendimiento de las aplicaciones desarrolladas con tecnología Velneo en particular.En esta segunda parte se comenta en qué consiste la ejecución multihilo, las problemáticas derivadas de la este tipo de programación, y como influye en la tecnología Velneo, así como diversas técnicas de optimización en Velneo del rendimiento para casos concretos.Todo lo dicho hasta ahora nos permite asegurar que es claramente ventajoso tener un sistema multiprocesador en vez de uno monoprocesador, de hecho un sistema equipado con procesador "dual core" o con procesador con hyperthreading (en menor medida) también tendrán un mayor rendimiento que un sistema monoprocesador clásico. Pero, ¿qué tiene esto que ver con el rendimiento del servidor de aplicaciones de Velneo en una máquina con múltiples procesadores? La ejecución simultánea de varios hilos de un mismo proceso es tratada por el sistema operativo según el mismo esquema de multitarea: cada hilo es tratado como un proceso por el scheduler del sistema; en este caso la multitarea no sólo proporciona un aumento del rendimiento del sistema en general, sino también del proceso multihilo en concreto. Dicho esto la pregunta que surge inmediatamente es la siguiente: ¿por qué no son todas las aplicaciones multihilo? Hay varias razones por lo que esto no es siempre viable o recomendable:Los hilos, a diferencia de los procesos, comparten entre ellos todos los datos que se deben acceder en memoria, puesto que se ejecutan en el mismo espacio. Esto tiene dos implicaciones importantes:Desaparecen los mecanismos de protección que el propio sistema aplica entre procesos para evitar accesos indebidos a datos.La coherencia de datos puede verse comprometida ante fallos en el sistema que alteren la secuencia normal de ejecución de los hilos.Un proceso monohilo es automáticamente identificable por el sistema operativo como tal, y el scheduler asigna recursos de CPU al bloque entero del proceso/hilo; en un proceso que se desea que sea tratado por el scheduler en modo multihilo (de manera que varias tareas de ese mismo proceso puedan ser ejecutadas simultáneamente aumentando así el rendimiento) cada hilo necesita ser identificado mediante programación específica; el sistema operativo no es capaz de reconocer un hilo dentro de un proceso, ya que en parte su definición depende de la estructura y funcionalidad con que los programadores han dotado al proceso global.La programación de hilos es compleja y requiere múltiples controles de sincronización (como el uso intensivo de mútex por ejemplo) que merman, en parte, las mejoras de rendimiento que se pueden obtener de la ejecución multihilo.La consecuencia de todo esto es que se debe ser muy cuidadoso a la hora de implementar la programación multihilo y sobre todo de seleccionar dónde y cómo implementarla. La tecnología Velneo implementa programación multihilo, directa o indirectamente, en buena parte de su código. Como en la mayor parte de las aplicaciones, en Velneo aparentemente hay un único proceso (VMotor.exe) en ejecución, y por lo tanto este se ejecuta en un único procesador del sistema, pero hay numerosos hilos derivados de él brindando diversas funcionalidades directamente o a través de dlls de sistema (las cuales son multihilo a su vez). Sin embargo, y dada la problemática comentada antes relativa a la coherencia de datos en la gestión de múltiples hilos de un mismo proceso, hay ciertas partes del servidor de aplicaciones de Velneo que no se ejecutan en modo multihilo. El caso más evidente, y el que mayor impacto tiene sobre el rendimiento del motor, es el módulo denominado gestor de accesos a disco (no confundir con el servidor de disco), e indirectamente el gestor de transacciones (en la medida en que depende del anterior). Aunque hay múltiples operaciones en tecnología Velneo que pasan por el gestor de accesos a disco, son sólo unas pocas, de entre las que además también pasan por el gestor de transacciones, las que pueden llegar a provocar situaciones aparentemente inexplicables como las comentadas inicialmente.Entre las operaciones que provocan este tipo de comportamientos, y a las que por lo tanto se les debe prestar especial atención al usarlas, cabe destacar las siguientes:
- Tubos de lista de importación, exportación, e internos en tercer plano (ver nota al respecto publicada por Velneo: http://forum.velneo.com/es/viewtopic.php?t=11128).
- Las actualizaciones a hermano contiguo.
- Las funcionas remotas que transaccionan, especialmente las ejecutadas contra el mismo servidor (ver nota al respecto publicada por Velneo: http://forum.velneo.com/es/viewtopic.php?t=11088).
- Importación y exportación de objetos del contenedor (texto, dibujo, binario, correo).
- Las tareas programadas y demonios, ya que tienen mayor prioridad que el resto de procesos.
- Deshacer transacciones.
- Tareas de mantenimiento: regeneración de índices, copias de seguridad…
Como ya se ha dicho el comportamiento "no multihilo" del servidor de aplicaciones Velneo en este tipo de operaciones, es una condición de diseño tendente a la protección de la coherencia de los datos gestionados por Velneo; evidentemente se está trabajando constantemente en la mejora del rendimiento del servidor de aplicaciones Velneo, y este es uno de los puntos principales bajo análisis constante. Sin embargo existen una serie de medidas que los programadores que usan tecnología Velneo pueden tener en cuenta para mermar estos efectos adversos sobre el rendimiento. A continuación se comentan algunas:
- Tener especial cuidado con el uso de las funciones remotas; deben ser cortas y efectuar un número reducido de operaciones; es mejor tener varias funciones remotas de pocas operaciones que una que haga muchas. Aconsejablemos revisar el Manual de optimización Cliente/Servidor.
- Las transacciones con muchas operaciones, y que se preveé que puedan llegar a durar más de 5 minutos, o aquellas que implican actualizaciones a hermanos contiguos, deben segmentarse en transacciones más reducidas, de manera para que liberen al gestor de transacciones para dar entrada a otras que están en cola.
