Esta página fue traducida automáticamente. Lee el original en inglés. English

Biblioteca de IBSurgeon

Firebird Performance Newsletter: Issue 1

Decidimos lanzar un boletín más o menos regular sobre “rendimiento de Firebird”, dedicado a pruebas de rendimiento, consejos, trucos, mejoras de configuración, etc.

En el primer número, tenemos lo siguiente:

Firebird 4 vs Firebird 3: ¡Buenas noticias para todos!

Desde 2019, cuando publicamos la primera colección de resultados de la prueba simple INSERT/UPDATE/DELETE, muchas personas nos han enviado resultados de sus servidores Firebird, y los hemos agregado a la hoja de cálculo y al gráfico correspondiente.

La prueba es una herramienta simple pero poderosa para medir y comparar el rendimiento de diferentes configuraciones de hardware+Firebird, que permite confirmar o refutar rápidamente un problema de hardware o configuración.

Recientemente hemos utilizado esta prueba para comparar el rendimiento de INSERT/UPDATE/DELETE de Firebird 4.0 (versión 4.0.0.2394, algunas compilaciones de la versión) y 3.0 (versión 3.0.8.33426, snapshot, pre-lanzamiento de la próxima 3.0.8, es estable como una versión menor, según las auto-pruebas de Firebird).

El entorno de prueba fue Intel i3-10100F 3.60GHz con SSD Samsung SSD 870QVO y unidad RAM (qSoft), con varios tamaños de RAM (16, 32, 64) y Page Buffers.

A continuación se muestra el gráfico, y aquí está la hoja de cálculo XLS con los resultados.

Como puede ver, en las mismas condiciones y con la misma configuración, Firebird 4 es aproximadamente un 10% más rápido que 3.0.8 en operaciones de escritura. Esto es definitivamente una buena noticia y otra señal de que es hora de echar un vistazo más de cerca a la próxima versión y comenzar los preparativos para la migración.

Por supuesto, el mejor enfoque será ejecutar la misma prueba en su propio servidor y ver la mejora real por usted mismo.

Vea cómo hacerlo »

Elección de la mejor instancia AWS EC2 para el máximo rendimiento de escritura de Firebird

Cada vez más empresas piensan en “mudarse a la nube”, y Amazon Web Service Elastic Cloud es uno de los “destinos en la nube” favoritos.

Sin embargo, AWS ofrece muchos tipos diferentes de instancias, ¿cómo elegir la mejor? ¡Por supuesto, haciendo las pruebas!

Realizamos las pruebas simples de INSERT/UPDATE/DELETE para 20 tipos de instancias y encontramos varias opciones realmente buenas para Firebird.

Tenga en cuenta: todos los precios en los cálculos y gráficos a continuación son para la región de Frankfurt de AWS EC2, se toman tal cual de aws.amazon.com, sin descuentos, pueden estar sujetos a impuestos adicionales y pueden cambiar con el tiempo, por lo que no considere los precios a continuación como definitivos o como una guía de compra exacta.

Aquí está el gráfico general y la hoja de cálculo XLS con los resultados:

Para simplificar, hemos creado la columna Operaciones, que esencialmente es la suma de Inserts+Updates+Deletes, y la hemos utilizado como métrica unificada de rendimiento de escritura:

Como puede ver, los siguientes 3 tipos de instancias son líderes en rendimiento (desde el punto de vista de las operaciones de escritura de Firebird):

Instancia Costo por hora para Linux Operaciones/por segundo

| z1d.xlarge | USD$0.45 | 45834 | | m5dn.2xlarge | USD$0.648 | 45198 | | m5d.2xlarge | USD$0.544 | 44150 |

Es interesante que los líderes no sean los tipos de instancias más caros. Por supuesto, debemos tener en cuenta que la prueba es de un solo hilo (y no se beneficia del número de núcleos) y no requiere una gran cantidad de RAM (porque la base de datos es solo de 3.6Gb), pero para las aplicaciones que requieren procesar rápidamente operaciones de escritura pico, estas instancias se ven realmente óptimas.

A pesar de que estos tipos de instancias no son los más caros (entre los probados), siguen siendo lo suficientemente caros como para pensar dos veces en el presupuesto, y dado que una de las ventajas anunciadas de la nube es la flexibilidad, tiene sentido comenzar con tipos de instancias VM más baratos, que podrían ser suficientes para servir nuestra base de datos Firebird, ¿verdad?

Para encontrar los tipos de instancias óptimos en cuanto a costo/rendimiento, creamos otra columna en nuestra hoja de cálculo: “Operaciones por 1 USD”.

Significa exactamente lo que dice: cuántas operaciones de escritura puede comprar por 1 USD.

La fórmula es la siguiente:

Operaciones_Por_Segundo * 3600 segundos en una hora / Precio por Hora

Como puede ver, desde este punto de vista, los líderes son diferentes:

Instancia Precio por hora Linux Operaciones por 1 USD Operaciones por segundo
c5d.xlarge USD$0,222 579062087 35709
c5ad.xlarge USD$0,2 565024995 31390
m5dn.xlarge USD$0,324 446037216 40143

El más interesante es el #3, m5dn.xlarge con un rendimiento máximo de ~40K/por segundo: está bastante cerca del líder de rendimiento z1d.xlarge con 45834 operaciones/segundo, pero es significativamente más barato.

En general, nuestra experiencia con AWS EC2 muestra que es un entorno estable y maduro, con muchas buenas características de seguridad/copias de seguridad/alta disponibilidad/etc., pero, como cualquier plataforma compleja, requiere experiencia (o experiencia externa) para tomar la decisión adecuada y no pagar facturas abrumadoras por aplicaciones con una carga no fantástica.

Resultados recientes de la prueba INSERT/UPDATE/DELETE

Entonces, como puede ver, la prueba simple puede ser útil no solo como una comparación entre hardware y Firebird, sino que también puede ahorrarle un par de dólares.

Hemos publicado un gráfico con los resultados recopilados recientemente y una hoja de cálculo XLS para jugar con ella, para que pueda verificarla usted mismo aquí.

A continuación se presentan 3 conclusiones obvias:

  1. Las unidades NVME realmente funcionan muy bien, así que si necesita un servidor Firebird potente, compre NVME para las bases de datos.
  2. La alta frecuencia de CPU es muy importante para el alto rendimiento de las bases de datos Firebird. A menudo, los proveedores le empujan a comprar procesadores de múltiples núcleos con menor frecuencia (<3Ghz), pero esto puede no ser la mejor opción para Firebird, y menos núcleos con mayor frecuencia pueden dar un mejor resultado.
  3. Si su perfil de carga de base de datos está fuertemente orientado a escritura, intente reducir los Page Buffers: haga experimentos con DefaultDbCachePages como 50K, 100K, 250K, etc. ¡Sería genial si comparte los resultados con nosotros!

Siéntase libre de investigar los resultados de las pruebas, y haga cualquier pregunta o envíe sugerencias.

En los próximos números del “Boletín de rendimiento de Firebird”

En el segundo número, mostraremos cómo configurar varias instancias SuperClassic para servir una base de datos (entre otras cosas, puede ser útil para dividir la carga entre varios puertos de red). Los planes para los próximos números son grandes: errores de configuración, pruebas de bases de datos cifradas, comparación avanzada del rendimiento de Firebird 4 con Firebird 3, optimización de índices, etc.

Si está interesado y desea recibir notificaciones sobre nuevos números, únase a nosotros en el Canal de Telegram FirebirdSQL.

Contáctenos

Por favor, contáctenos con cualquier pregunta o sugerencia: Alexey Kovyazin: [email protected].