Cuando se instala el Firebird tenemos la opción de elegir la arquitectura:

  • Classic
  • SuperClassic
  • SuperServer

¿Por qué hay varias arquitecturas?

Porque difieren en como manejan las conexiones múltiples (porque Firebird, aunque puede ser usado en aplicaciones mono-usuario fue creado para ser usado mayormente en aplicaciones multi-usuario), y esa diferencia se refleja en el consumo de memoria RAM.

¿Hay una arquitectura que es mejor en todos los casos?

No, si la hubiera, esa sería la única que existiría. ¿Para qué tener varias arquitecturas si una de ellas le superara en todo a las demás? No tendría sentido. Por lo tanto, el hecho de existir varias arquitecturas significa que cada una de ellas es mejor que las otras en alguna tarea.

¿Cuál arquitectura debo elegir?

La elección depende de la computadora, del Sistema Operativo y de la cantidad de usuarios que se conectarán al mismo tiempo (en Informática se dice: concurrentemente) a la Base de Datos.

En Windows, hasta unos 25 usuarios puedes instalar SuperServer, funcionará bien. En Linux, cualquiera. Si tu computadora es de 64 bits, SuperClassic puede ser la mejor elección (instalando la versión de 64 bits, por supuesto); pero si es de 32 bits SuperClassic será el primero que se quedará sin memoria.

¿Elegir alguna de esas arquitecturas afectará a las bases de datos o a las aplicaciones?

No, las bases de datos continuarán exactamente igual sea cual sea la arquitectura elegida, nada cambiará dentro de ellas y nada debes modificar. Las bases de datos no saben con cual arquitectura estás accediendo a ellas. Igualmente, nada debes cambiar dentro de tus aplicaciones. Los que cambian son los servidores, no las bases de datos.

¿Qué implica elegir una de esas arquitecturas?

Procesos:

    • Classic usa un proceso separado (único) para cada conexión
    • SuperClassic usa un solo proceso para todas las conexiones
    • SuperServer usa un solo proceso para todas las conexiones

¿Qué ocurrirá si hay un problema grave en un proceso? si usas Classic, los demás procesos no se verán afectados; en cambio si usas SuperClassic o SuperServer finalizarán todas las conexiones, con todas las nefastas consecuencias que te puedas imaginar. Por lo tanto, desde este punto de vista lo mejor sería que uses Classic.

Guardian:

    • Classic no usa al Guardian
    • SuperClassic puede usar al Guardian en Linux pero no en Windows
    • SuperServer sí puede correr bajo el control del Guardian

¿Para qué sirve el Guardian? Para reiniciar el Servidor automáticamente en el caso de una falla grave. Desde este punto de vista, el mejor es SuperServer.

Recursos:

    • Classic usa más recursos (más memoria RAM) que las demás arquitecturas porque cada conexión requiere de memoria RAM para el proceso y para la memoria cache
    • SuperClassic necesita más memoria RAM cuando hay más usuarios conectados porque cada conexión requiere de memoria cache
    • SuperServer usa siempre la misma cantidad de memoria RAM, sin importar la cantidad de conexiones

Cada conexión en Classic requiere de una “X” cantidad de memoria RAM (por defecto: 300 kilobytes), eso significa que si la cantidad de conexiones se incrementa también lo hará la memoria RAM consumida. En cambio SuperServer usa siempre la misma cantidad de memoria RAM, sin importar cuantos usuarios estén conectados. Desde este punto de vista, SuperServer es mejor.

Conexiones locales:

    • En Linux, Classic y SuperClassic ofrecen un modo “embedded” que es muy rápido aunque poco seguro en cuanto al acceso
    • En Windows, en un solo archivo se tienen el Servidor y el Cliente “embedded”, el cual es aún más inseguro en cuanto al acceso

¿Por qué usar una conexión local? Porque eso nos permite tener en un CD, DVD, pen-drive u otro dispositivo removible nuestra aplicación y nuestra Base de Datos, lo cual lo hace muy útil para programas de catálogo, programas de demostración, etc. O sea que en un pen-drive podríamos tener todo lo que necesitemos sin necesidad de instalar algo en las computadoras ajenas, de nuestros potenciales clientes.

Conexiones simultáneas:

    • Classic permite conexiones simultáneas a una Base de Datos desde un Servidor normal y desde uno o más servidores “embedded”
    • SuperClassic permite conexiones simultáneas a una Base de Datos desde un Servidor normal y desde uno o más servidores “embedded”
    • SuperServer no permite conexiones simultáneas a una Base de Datos desde un servidor normal y uno o más servidores “embedded”

Esto significa que puede ser ventajoso que tu Servidor normal sea Classic o SuperClassic si simultáneamente necesitas conectarte a la Base de Datos desde un servidor “embedded”

Multiprocesamiento:

    • Todas las arquitecturas (exceptuando SuperServer en Windows) ya están preparadas por defecto para usar todos los procesadores o cores de las computadoras
    • SuperServer en Windows por defecto usa solamente el primer procesador o core. Para que use más procesadores se debe modificar el parámetro CpuAffinityMask en el archivo FIREBIRD.CONF

Fuera de memoria:

    • Classic usa más memoria RAM que las otras arquitecturas cuando la cantidad de conexiones se incrementa. Cada conexión usará (por defecto) 300 Kilobytes
    • En 32 bits SuperClassic será el primero en quedarse sin memoria
    • El consumo de memoria por SuperServer es fijo, sin importar la cantidad de usuarios conectados. Por defecto esa cantidad es de 8 Megabytes

Por lo tanto, si habrá hasta 25 usuarios conectados suele ser preferible usar SuperServer pero cuando la cantidad de usuarios conectados sea mayor Classic será una mejor elección en 32 bits y SuperClassic en 64 bits.

Problema con operaciones intensivas:

    • Classic no tiene problemas con las operaciones intensivas
    • Supper Classic y SuperServer pueden encontrarse con un “cuello de botella” si una transacción está teniendo mucho tráfico en la red (por ejemplo un SELECT que trae millones de filas)

Un SELECT que traiga más de 100 filas con seguridad está mal diseñado pero a veces esos errores de diseño ocurren. En tal caso dicho SELECT estará consumiendo demasiados recursos y si se está usando SuperClassic o SuperServer todas las demás transacciones se verán afectadas. Dicho problema también podría ocurrir si se están haciendo inserciones masivas (por ejemplo, migrando todo el contenido de  una tabla .DBF en una tabla de Firebird)

Para estos casos, Classic es el mejor.

Unos gráficos explicativos

Dicen que un gráfico es mejor que mil palabras, así que espero que estos gráficos te ayuden a entender mejor todo lo anterior

ClassicServerDiagram(1)

SuperClassicDiagram

SuperServerDiagram

Como puedes ver, Classic ejecuta un proceso (una instancia del programa FBSERVER.EXE) para cada conexión. Tambien la memoria cache utilizada aumenta con cada conexión (si hay una conexión se usará “X” memoria, pero si hay dos conexiones se usará “2X” memoria, si hay tres conexiones se usará “3X” memoria y así sucesivamente).

SuperClassic y SuperServer usan un solo proceso (una sola instancia del programa FBSERVER.EXE) sin importar cuantos usuarios estén conectados. Pero el consumo de memoria cache es distinto: mientras que SuperClassic aumenta la memoria cache junto con la cantidad de usuarios, SuperServer no lo hace así: la memoria cache utilizada es siempre la misma, sin importar cuantos usuarios estén conectados.

Conclusión:

La arquitectura elegida puede afectar grandemente el rendimiento o desempeño de tus aplicaciones. Como elegir una arquitectura u otra no afectará a las bases de datos lo más conveniente suele ser el viejo método informático de “prueba y error”. Pruebas con una, si no te satisface pruebas con otra y si tampoco te satisface pruebas con la tercera. En otro artículo explicaré como cambiar el tamaño de la memoria cache y otros parámetros que afectan al rendimiento y desempeño de las aplicaciones. Mediante ellos podrás conseguir mayor velocidad en todas las operaciones.

.

Anuncios