Migrando a MariaDB en Gentoo
Gracias a qué Oracle ,con la adquisición de MySQL, le esta haciendo perder velocidad desde hace algún tiempo, creemos que es para favorecer al hermando mayor “Oracle DB” y tienes otros problemas de cara a la comunidad de desarrolladores, por eso pensamos que MariaDB tiene un gran futuro.
Es en este pequeño vamos a explicar de forma sencilla los pasos a seguir para migrar una instalación con MySQL a MariaDB en Gentoo, algunos de estos pasos también podríais aplicarse a otras distribuciones, simplemente seria cambiar los comandos de instalación.
- Backup de todas las base de datos por si tenemos que ir marcha atrás.
mysqldump -A >all.sql
- Actualmente en Gentoo MariaDB se encuentra en fase de pruebas con lo que tendremos que añadir lo siguiente en los fichero /etc/portage/package.keywords.
dev-db/mariadb
virtual/mysql - Igualmente tendremos que copiar nuestra configuración de dev-db/mysql en /etc/portage/package.use para no perder nuestra personalización.
Recomendamos usar el flag jemalloc para mejorar el rendimiento. - Paramos la el motor MySQL.
/etc/init.d/mysql stop
- Desinstalamos MySQL
emerge -C mysql
- Instalamos MariaDB.
emerge mariadb
- Y por si tenemos alguna dependencia rota o librería.
emerge @preserved-rebuild
revdep-rebuild - Arrancamos la base de datos.
/etc/init.d/mysql start
- Por ultimo actualizamos las tablas.
mysql_upgrade -u root -p
mysqlcheck --repair --all-databases -u root -p
Y a disfrutar de la velocidad de MariaDB.
Referencias:
¿Por qué Gentoo?
Nosotros usamos en todos nuestros servidores Gentoo, aunque no es una distribución sencilla, tiene grandes ventajas si se consigue dominar, entre ellas destacamos:
- Un ciclo de actualizaciones 'sobre la marcha', que nos permite actualizarlos de forma lineal, cuando nosotros queremos o realmente hace falta por motivos de seguridad o alguna nueva funcionalidad. Y no esperar años y luego tener que cruzar los dedos para qué todos los servicios funcionen correctamente. Incluso podemos bloquear para que no se actualicen ciertos componentes del sistema e igualmente el resto del sistema completo puede ir evolucionando.
- Permite de forma sencilla crear tu propio repositorio y tener un sistema de compilación donde replicar los cambios al resto de servidores, antes también realizábamos rpms personalizados pero no es tán cómodo y práctico como un ebuild.
- Optimizar el sistema para un determinado procesador y hardware.
- Simplificar las dependencias y protocolos no necesarios, evitamos así posibles errores de programación, vulnerabilidades y reducir el uso de memoria.
Comparativa entre Joomla 2.5 y 3.0 (PHP 5.3 y PHP 5.4)
Hemos usado como banco de pruebas gk_magazine un template de Gavick que se encuentra optimizado tanto para Joomla 2.5 como 3.0 para intentar ser los mas justos posible y usando en los dos casos el quickstart para que en contenido de la pagina principal tuviera un contenido mas parecido a una web real.
| Joomla 2.5 | Joomla 3.0 | |
| PHP 5.3 | 38,529 | 34,050 |
| PHP 5.4 | 37,235 | 33,353 |
| PHP 5.3 + Xcache | 30,356 | 26,836 |
| PHP 5.4 + Xcache | 28,680 | 25,763 |
| PHP 5.3 + Xcache + Cache Conservacional | 28,086 | 25,014 |
| PHP 5.4 + Xcache + Cache Conservacional | 26,364 | 23,881 |
| PHP 5.3 + Xcache + Cache Progresiva | 20,852 | 19,469 |
| PHP 5.4 + Xcache + Cache Progresiva | 20,508 | 19,307 |
En conclusión vemos que es un poco mas rápida la versión de Joomla 3.0 pero esa diferencia es imperceptible cuando se activa la cache progresiva. Algo similar sucede con PHP 5.4 donde el aumento de velocidad no es muy significativo, donde lo más destacado es usar un sistema de cache para PHP como son XCache o APC, pero este ultimo nos ha dado algún problema y lo hemos tenido que reemplazar en nuestros servidores de producción.
Sistema de evalucion usado:
PHP 5.3.23
PHP 5.4.13
Version Xcache 3.0.1
Version Joomla 2.5.9
Version joomla 3.0.3
Apache 2.2.24
kernel 3.7.10 64bits
GCC 4.5.4
Sistema de archivos EXT4
Procesador AMD Athlon(tm) II X2 255 Processor
Memoria ram de 2Gb
Placa Base Gigabyte GA-MA785GMT-UD2H
XCache de 1G
ab -n 200 -c 5 http://localhost/j25/
ab -n 200 -c 5 http://localhost/j30/
Comparativa Python 2.6 vs 2.7
Este test de rendimiento entre las diferentes versiones de python y los diferentes "Template Engine" (django, cheetah, kid, genshi, mako y Tenjin), usando como herramienta los benchmark proporcionados por Tenjin
Usando como banco de pruebas un ordenador con Gentoo Linux 64Bits:
Model name : AMD Athlon(tm) II X2 255 Processor
cpu MHz : 3100.000
bogomips : 6228.15
Linux version 2.6.39-gentoo-r3
gcc 4.4.6
glibc 2.13
cheetah-2.4.4 genshi-0.6 django-1.3.1 kid-0.9.6
jinja-2.6 mako-0.4.2 Tenjin-1.0.2 utime stime total real
tenjin 2.4400 0.0000 2.4400 2.4411
tenjin-create 3.0300 0.1100 3.1400 3.1322
tenjin-str 1.5600 0.0000 1.5600 1.5670
django 49.9200 0.0000 49.9200 49.9329
django-create 59.8000 0.1300 59.9300 59.9716
cheetah 10.0900 0.0000 10.0900 10.0893
cheetah-create 10.2500 0.0000 10.2500 10.2529
kid 169.5000 0.0000 169.5000 169.5634
kid-create 170.6300 0.0200 170.6500 170.7134
genshi 104.9000 0.0000 104.9000 104.9571
genshi-create 203.4300 0.2900 203.7200 203.9146
mako 3.2700 0.0000 3.2700 3.3075
mako-create 5.1400 0.1600 5.3000 5.2996
mako-nocache 69.0900 0.3600 69.4500 69.5108
jinja2 4.1800 0.0000 4.1800 4.1941
jinja2-create 82.5500 0.3800 82.9300 83.0065 utime stime total real
tenjin 1.9900 0.0000 1.9900 1.9957
tenjin-create 2.6000 0.1100 2.7100 2.7158
tenjin-str 1.2000 0.0000 1.2000 1.1962
django 48.4400 0.0000 48.4400 48.4615
django-create 57.6800 0.1400 57.8200 57.8634
cheetah 9.4500 0.0000 9.4500 9.4498
cheetah-create 9.7400 0.0000 9.7400 9.7356
kid 169.4400 0.0000 169.4400 169.5022
kid-create 170.5300 0.0200 170.5500 170.6074
genshi 102.5700 0.0000 102.5700 102.6323
genshi-create 201.6100 0.2800 201.8900 202.0769
mako 2.8600 0.0100 2.8700 2.8641
mako-create 4.8700 0.1500 5.0200 5.0314
mako-nocache 70.3000 0.3700 70.6700 70.7403
jinja2 3.5600 0.0100 3.5700 3.5751
jinja2-create 82.3000 0.3400 82.6400 82.7155 utime stime total real
tenjin 2.0600 0.0000 2.0600 2.0543
tenjin-create 2.7100 0.1000 2.8100 2.8148
tenjin-str 1.1700 0.0000 1.1700 1.1727
django 48.1300 0.0000 48.1300 48.1483
django-create 58.2200 0.1400 58.3600 58.3909
cheetah 9.4900 0.0000 9.4900 9.4995
cheetah-create 9.6700 0.0000 9.6700 9.6683
kid 171.1300 0.0000 171.1300 171.1886
kid-create 173.3100 0.0300 173.3400 173.4043
genshi 104.9000 0.0000 104.9000 104.9526
genshi-create 203.9500 0.2800 204.2300 204.4071
mako 2.7700 0.0000 2.7700 2.7746
mako-create 4.6800 0.1600 4.8400 4.8590
mako-nocache 69.8400 0.3700 70.2100 70.2735
jinja2 3.5700 0.0100 3.5800 3.5831
jinja2-create 82.4000 0.3800 82.7800 82.8525Benchmark basados en el codigo Spitfire performance tests:
Genshi tag builder 308.61 ms
Genshi template 179.08 ms
Genshi template + tag builder 338.64 ms
Mako Template 39.34 ms
Kid template 706.16 ms
Djange template 371.56 ms
Cheetah template 42.14 ms
StringIO 47.67 ms
cStringIO 8.07 ms
list concat 5.09 msGenshi tag builder 313.95 ms
Genshi template 172.67 ms
Genshi template + tag builder 337.62 ms
Mako Template 34.99 ms
Kid template 702.53 ms
Djange template 370.30 ms
Cheetah template 42.43 ms
StringIO 46.91 ms
cStringIO 7.30 ms
list concat 4.90 msGenshi tag builder 305.27 ms
Genshi template 180.95 ms
Genshi template + tag builder 332.87 ms
Mako Template 33.85 ms
Kid template 712.32 ms
Djange template 355.89 ms
Cheetah template 39.50 ms
StringIO 45.37 ms
cStringIO 6.86 ms
list concat 4.66 msComo resultado hay que decir que el Python 2.7 es ligeramente mas rápido que su versión anterior la 2.6
Mientras que el cambio de GCC 4.4.6 a 4.5.3 se gana en ciertas partes otras se pierde, aun le faltaran pulir las regresiones.