Hacía años que el calor no pegaba tan fuerte aquí en el valle del Guadalquivir, al menos que yo recuerde, así que he tardado unas 24 horas más de lo que suelo tardar semanalmente en colgar este extracto de noticias interesantes aparecidas en la red. El calor aprieta y las ganas de bloguear o de programar, bajan. Menos mal que existe al aire acondicionado… pero bueno, a lo que íbamos, aunque hay algo más de aparcamiento en las ciudades del interior, el ritmo de blogosfera hispana no decae y hay entradas interesantes que referiros:
Hace unos días hablamos de cómo activar la caché de MySQL. Espero que la hayáis probado y que hayáis visto cómo vuestros tiempo de consulta se reducen considerablemente con sólo activarla. Os dije que os comentaría cómo monitorizarla y de esa promesa, esta entrada.
Soy de los que dice que algo por bien que funcione, si no puede medirse, no funciona tan bien. Las sensaciones son esos y aunque veamos que el tiempo de ejecución ha caído, no sabemos nada sobre la caché. Todos los que hayáis estudiado algo relacionado con la informática, conoceréis conceptos como la tasa de fallos y de aciertos de cualquier caché y ésta, no podía ser menos.
¿Cómo podemos ver esos datos? Veamos.
Comprobar si la caché está activada
Para esta labor usaremos el siguiente comando (siempre desde la consola de MySQL):
SHOW VARIABLES LIKE 'have_query_cache';
Que nos devolverá si está activada lo siguiente:
+------------------+-------+ | Variable_name | Value | +------------------+-------+ | have_query_cache | YES | +------------------+-------+
Parámetros de estado
Para ver todos los parámetros del estado de la caché, una vez sabemos que está activada hacemos:
SHOW STATUS LIKE 'Qcache%';
Y el resultado es el siguiente:
+-------------------------+-----------+ | Variable_name | Value | +-------------------------+-----------+ | Qcache_free_blocks | 3409 | | Qcache_free_memory | 501720656 | | Qcache_hits | 3265000 | | Qcache_inserts | 1321208 | | Qcache_lowmem_prunes | 0 | | Qcache_not_cached | 72160 | | Qcache_queries_in_cache | 10027 | | Qcache_total_blocks | 24143 | +-------------------------+-----------+
La velocidad es algo básico en la red. Es de tal relevancia, que hoy en día se valora como un factor más a la hora de posicionarte en el mundo de los buscadores, el llamado Google Speed Index. La red está llena de sitios hacen consultas a bases de datos MySQL, así que una buena idea sería optimizar esta interacción.
Comenzaremos hoy con algo básico. A la hora de hacer consultas es muy típico que hagamos algo así como:
SELECT * FROM personas
Cuando en realidad solo queríamos dos campos de la tabla personas: nombre y apellidos por ejemplo:
Cada vez que accedemos a una web, independientemente del CMS que usemos (como si no usamos ninguno), el navegador empieza la descarga del sitio en HTML y todo lo que trae consigo (principalmente imágenes, hojas de estilo y ficheros de script del lado del cliente como JavaScript) mediante protocolo HTTP.
¿Qué problema tiene HTTP? Para cada petición de este tipo, abre y cierra la conexión. ¿Eso qué conlleva? Un aumento del tiempo de transferencia.
Como se puede observar, el problema en parte es abordable ya que aunque no podemos (por ahora) reunir todas las imágenes en una sola transmisión, sí que es cierto que podemos hacer que si tenemos 4 ficheros de hojas de estilo CSS y 10 ficheros JavaScript que cargar; podemos limitarnos a enviar un sólo fichero de cada tipo al navegador. El resultado no cambia y aceleramos el proceso.
Si usamos WordPress, podemos instalar WP Minify para que automatice este proceso por nosotros y nos olvidemos, junto con otra mejora, comprime ambos ficheros resultantes lo que lleva a una mejora mayor aún de la ya comentada.
Podéis ver el efecto de usarlo en las capturas siguientes:
Últimamente venía notando que mi equipo no dejaba de usar los ventiladores aunque pensara que no estaba haciendo un uso excesivo de la CPU como para que requiera mejor ventilación. Así pues, me doy cuenta de que el sensor de los ventiladores no es detectado y que siempre están al 100%.
Para algunos estos puede ser una ventaja, pero esta claro que en el día en que vivimos y con la de avances tecnológicos que tenemos, usar un dispositivo sin control mientras que sí podemos controlarlo puede parecer absurdo, de hecho lo es. El ventilador debe de ser controlado en función del nivel de temperatura de nuestro equipo.
El otro día os comentaba como monitorizar nuestros discos en Linux. Esto puede resultar muy útil cuando estamos utilizando una aplicación y deseamos conocer el acceso y grado de utilización a los dispositivos de E/S.
En el caso de que queramos saber qué capacidad máxima de lectura y escritura tiene nuestro disco (o dispositivo externo) utilizaremos las aplicaciones hdparm y dd como os comento a continuación.
Para obtener la velocidad de lectura del disco:
ahornero@6581-D$ sudo hdparm -tT /dev/sda1
