Archivo de Etiquetas de 'awk'

Refréscame esa caché

Wordpress, el CMS que uso para gestionar mi blog, dispone de varios plugins para acelerar su carga mediante cachés, algo muy necesario en general, y más si, como yo, eres usuario de un servicio de hosting barato.

En mi caso, el plugin de caché que estoy usando es WPSuperCache, que guarda una copia estática de cada página generada por Wordpress, y la sirve directamente en próximas peticiones, siempre y cuando el usuario no esté registrado. Esto evita todas las peticiones contra la base de datos por parte de Wordpress. Además, opcionalmente, el plugin permite guardar las páginas estáticas con una estructura de directorios equivalente a la URL que las representa, y proporciona reescrituras de URL para llegar a dichas páginas directamente, evitando toda intervención por parte de Wordpress (y evitando, por lo tanto, la ejecución de código PHP en el servidor). Finalmente, además, te da la opción de guardar los archivos HTML comprimidos con GZip. Todas estas opciones aceleran notablemente la carga de la página, puesto que el único trabajo que debe realizarse es el del servidor web: encontrar la página html y servirla.

WPSuperCache, como la mayoría de plugins de caché, cuenta con un borrado automático de la caché cada cierto tiempo. Cada vez que se ejecuta esta tarea, las siguientes peticiones (si las hay :-D ) a las distintas páginas del blog harán que se regenere la caché automáticamente.

Sin embargo, cuando tienes pocas visitas, no es buena idea hacer que la caché sea regenerada por los lectores. En ese caso, el mío :-) , es probable que un lector obtenga una página no cacheada en vez de una que sí lo está. Una posiblidad es aumentar en gran medida el intervalo de borrado de la caché, pero en general es preferible tener una caché actualizada. La otra posiblidad es, además de borrar la caché, regenerarla automáticamente, de tal manera que todos los lectores del blog se beneficien de la caché del mismo.

En mi caso, he escrito un script que visita todos los enlaces de una página web basándose en el sitemap de la misma, siempre que este cumpla el protocolo descrito por Sitemaps.org. El código es el siguiente:

#!/bin/bash
# Visit all the links provided by a sitemap file.
# Diego Toharia - http://blog.deigote.com

# Verify parameter
if [[ $# -ne 1 ]] ; then
    echo "Error: first parameter (sitemap URL) missing"
    echo "Usage: `basename $0` "
    exit 1
fi

url=$1
links=`wget -q -O - http://blog.deigote.com/sitemap.xml | awk '{ print $1 }' | grep "^http" | awk 'BEGIN { FS=">" } { print $2 }' | awk 'BEGIN { FS="<" } { print $1 }'`

for i in $links ; do
	echo "Visiting " $i
	wget -q -O - $i > /dev/null
done

Seguro que hay formas más elegantes de hacerlo, pero awk es tan potente que es difícil resistirse a usarlo :-D . Lo he llamado visit_site_by_sitemap, original que es uno :roll: .

Una vez tenemos el script, lo más fácil es programar una tarea del cron que cada cierto tiempo (preferiblemente, en franjas horarias con el menor tráfico posible) borre la caché y ejecute el script pasándole como parámetro la URL del sitemap. Por cierto que, en mi caso, el sitemap lo genera el plugin Google Sitemap Generator. El mandato para la regla en mi caso sería algo como:

cd path/al/blog/wp-content ; find cache -type f -name '*.html' -exec rm {} \; -o -name '*.gz' -exec rm {} \; ; ~/bin/visit_site_by_sitemap http://blog.deigote.com/sitemap.xml

La idea es borrar todos los ficheros html y gz generados por la caché y regenerar la misma visitando todos los enlaces proporcionados por el sitemap del blog.

Podemos hacer un par de pruebas que, sin ser demasiado científicas, nos dan una idea del beneficio que obtenemos. La primera sería ejecutar en local el script dos veces, previo borrado de la caché. La primera visitaría todos los enlaces sin disponer de caché, mientras que la segunda lo haría usando la caché.

$ cd path/al/blog/wp-content
$ find cache -type f -name '*.html' -exec rm {} \; -o -name '*.gz' -exec rm {} \;
$ time ~/bin/visit_site_by_sitemap http://blog.deigote.com/sitemap.xml
Visiting  http://blog.deigote.com/
...
real    4m12.102s
$ time ~/bin/visit_site_by_sitemap http://blog.deigote.com/sitemap.xml
Visiting  http://blog.deigote.com/
...
real	0m7.759s

Podemos ver que los resultados son espectaculares. De 4 minutos hemos pasado a 7 segundos. Sin embargo, estamos probando el caso óptimo, en el que la latencia es mínima y la velocidad de conexión con el servidor web es máxima, lo que hacen que la capacidad de proceso sea el único parámetro que influye en los resultados.

Si ejecutamos esta misma prueba en una máquina externa y situada en España, la misma desde la que estoy escribiendo, obtenemos unos resultados bien distintos: casi trece minutos (12m45) frente a casi 9 (8m44s).

Sin embargo, esto es culpa de la lamentable latencia y velocidad de conexión que Dreamhost tiene en España, ya que ejecutando la prueba en una máquina situada en USA (y de otro servicio de hosting distinto), se obtienen 3 minutos (3m02s) frente a 22 segundos, resultados más parecidos a la ejecución en local. Tendré que pensar seriamente en cambiar de hosting :cry: .

La otra prueba que se puede hacer es algo más realista: medir el tiempo de descarga de una única página, que es lo que hace un usuario cualquiera (no creo que tenga ningún lector tan fan como para visitarse todas las entradas del blog una detrás de otra :lol: ). En mi caso, he usado un navegador Firefox con la caché deshabilitada y con la extensión Firebug instalada, usando la pestaña Red de dicha extensión para medir el tiempo de carga del HTML de la página de inicio. He realizado varias pruebas con la caché vacía y con la caché llena y he obtenido de media unos 2.5 segundos frente a medio segundo respectivamente, lo cual no está mal. Sin embargo, el resto de elementos de la página (malditos emoticonos :evil: ) ralentiza la carga total de la misma en gran medida, aunque eso es otra historia :-) .

Gracias a Álvaro por su inestimable ayuda a la hora de lanzar el juego de pruebas :P en un servidor externo a españa.

Si la salida fuese un Excell, lo llamaríamos ingeniería del software

Lo que ha empezado como un simple conteo de ficheros para ver qué proyecto hacía que Eclipse fuese lento, ha terminado en todo un contador de líneas digno de aparecer en cualquier libro de ingeniería del software (nótese la cursiva, por favor :???: ), si no fuera porque es un script de consola bash con salida de texto simple.

Al grano:

#!/bin/bash
EXTENSIONES="$@"
ficheros_total=0
lineas_total=0
vacias_total=0
novacias_total=0
for ext in $EXTENSIONES ; do
   echo EXTENSION $ext
   ficheros=`find . -name "*.$ext" | wc -l`
   lineas=`find . -name "*.$ext" | xargs cat | wc -l`
   novacias=`find . -name "*.$ext" | xargs cat | awk 'BEGIN { lineas = 0 } { if ($0 != "") lineas++} END { print lineas }'`
   vacias=`find . -name "*.$ext" | xargs cat | awk 'BEGIN { lineas = 0 } { if ($0 == "") lineas++} END { print lineas }'`
   porcentaje=`echo $vacias $lineas | awk '{ print $1 / $2 * 100 }'`
   echo Tiene $ficheros ficheros de tipo $ext y $lineas lineas, de las cuales $novacias tienen contenido y $vacias son vacias \(un $porcentaje %\)
   ficheros_total=`expr $ficheros_total + $ficheros`
   lineas_total=`expr $lineas_total + $lineas`
   vacias_total=`expr $vacias_total + $vacias`
   novacias_total=`expr $novacias_total + $novacias`
done
if [[ $# -gt 1 ]] ; then
   porcentaje_total=`echo $vacias_total $lineas_total | awk '{ print $1 / $2 * 100 }'`
   echo TOTAL
   echo Tiene $ficheros_total ficheros en total, con $lineas_total lineas, de las cuales $novacias_total tienen contenido y $vacias_total son vacias \(un $porcentaje_total %\)
fi

Ejemplo de uso (guardandolo en un fichero cuenta_lineas.sh accesible por el path y con los permisos adecuados):

$ cd directorio_raiz_del_proyecto/ ; ./cuenta_lineas.sh java jsp xml
EXTENSION java
Tiene 388 ficheros de tipo java y 60035 lineas, de las cuales 47806 tienen contenido y 12230 son vacias (un 20.3714 %)
EXTENSION jsp
Tiene 792 ficheros de tipo jsp y 91354 lineas, de las cuales 75267 tienen contenido y 16088 son vacias (un 17.6106 %)
EXTENSION xml
Tiene 170 ficheros de tipo xml y 32282 lineas, de las cuales 30437 tienen contenido y 1846 son vacias (un 5.71836 %)
TOTAL
Tiene 1350 ficheros en total, con 183671 lineas, de las cuales 153510 tienen contenido y 30164 son vacias (un 16.4228 %)

Mola :mrgreen: aunque es mejorable sacando porcentajes (ver abajo :-D ), pero no he encontrado un mandato tipo expr que trabaje con floats :neutral: (a ver si algún comentarista me da el tip :-) )

EDITO: Ya se me ha ocurrido cómo hacer los porcentajes mientras contestaba :lol: actualizado el código y la salida del mismo

EDITO de nuevo: Si queréis añadir más filtros a las lineas vacías, tal y como sugiere Kortatu (que yo ya he barajado), tendréis que cambiar la línea

novacias=`find . -name "*.$ext" | xargs cat | awk 'BEGIN { lineas = 0 } { if ($0 != "") lineas++} END { print lineas }'`

por

novacias=`find . -name "*.$ext" | xargs cat | grep -v '^$' | grep -v '^\s*\}\s*$'  | grep -v '^\s*\*.**$' | grep -v '^\s*/\*\*.*$' | grep -v '^\s.//.*$'

Útil para código de la familia Java :D. ¡Gracias!

Mini tutorial de awk

Por petición popular, voy a escribir un poco sobre un mandato típico de los sistemas operativos UNIX (apareció por primera vez en 1977 nada menos), awk.

awk es un mandato que sirve para procesar líneas de texto (separadas, naturalmente, por un salto de línea). awk cuenta con un pequeño y sencillo lenguaje de programación que es interpretado (no necesita ser compilado), y resulta tremendamente útil cuando queremos extraer información de extensos campos de texto (y, posiblemente, manipularla).

El funcionamiento del madato awk es muy sencillo: basicamente tenemos dos posiblidades:

$ awk -f fuente.awk fichero_entrada.txt
$ awk 'fragmento de código fuente' fichero_entrada.txt

En la primera de ellas, el código fuente está en un fichero (recomendado para usos que vayan a repetirse con el tiempo y con códigos fuentes largos) mientras que el segundo ofrece la ventaja de poder poner el código fuente como un argumento más. Esto es muy útil para el uso de awk en scripts o similares, en los que el uso de ficheros puede ser un engorro. También cabe la posibilidad de omitir el fichero de entrada, en cuyo caso awk leerá de la entrada estándar.

Respecto al lenguaje awk, tiene una estructura similar a lo siguiente:

BEGIN { acción }
/patrón/ { acción }
END { acción }

La forma de funcionamiento la siguiente:

  1. Nada más comenzar la ejecución, se evaluará la acción marcada entre llaves precedida por la palabra reservada BEGIN.
  2. Por cada campo de texto (recordemos, por defecto líneas) awk evaluará si se ajusta al patrón (una expresión regular), y de ser así, ejecutará la acción marcada entre llaves que sigue a dicho patrón. Por cada líneas se evaluarán todos los patrones a menos que en una de las acciones ejecutadas se encuentre la orden next, en cuyo caso se comenzará desde el principio con la siguiente línea.
  3. Finalmente, se procesará la acción marcada entre llaves precedida por la palabra reservada END.

Respecto a los patrones de awk, son, como ya he dicho, expresiones regulares. No voy a explicar aquí todas las posiblidades porque no acabaría nunca (y con la ayuda de la Wikipedia os debería bastar), basten un par de ejemplos:

  • /[afP]MEMOLO[1-3]z/ casará con cualquier línea que contenga las letras a, f o P seguidas de la cadena MEMOLO seguidas de un dígito comprendido del 1 al 3 y seguida por la letra z.
  • /[afP](MEMOLO)+([1-3])*z/ casará con cualquier línea que contenga las letras a, f o P seguidas de la cadena MEMOLO una o varias veces seguidas de un dígito comprendido del 1 al 3 que puede aparecer ninguna, una, o varias veces y seguida por la letra z.

Esta es la parte más complicada de awk (ya sabeis lo que se dice de las expresiones regulares).

En cuanto a las acciones, cualquiera que haya programado en C no tendrá mucho problema, ya que es similar. Como características cabría destacar:

  • El acceso a las línea actual se hace mediante unas variables especiales. En concreto $0 referencia a toda la línea mientras que $1, $2, etcétera, referencian a los campos de dicha línea. El separador de campos por defecto es un espacio o un tabulador, pudiéndose modificar en la acción de BEGIN con la variable FS (otra expresión regular, por cierto).
  • No es necesario declarar ni tipar las variables, cuyo formato es el mismo que en C (su expresión regular, para que vayais practicando, es algo parecido a [a-Z]([a-Z] | [1-9] | _ )*).
  • Están permitidas todas las estructuras clásicas de programación en un formato estilo C (bucles, expresiones condicionales, operadores, etcétera).
  • Para imprimir resultados, existen dos posiblidades. La primera, print, es la más cómoda, puesto que no es necesario usar paréntesis para sus argumentos y cuenta con concatenación automática de los mismos (algo parecido al mandato echo de la terminal. Por ejemplo, print “la línea ” $0 “tiene ” NF ” palabras” imprimirá la frase que precede a print sustituyedo $0 por la línea actual y NF (otra variable especial) por el número de campos de la misma. Como segunda posibilidad, tenemos printf, que ofrece mayor control (es idéntico al del lenguaje C).

¿Y qué pasa con los los jugosos ejemplos? Pues he recopilado alguno que otro según me ha ido surgiendo la necesidad de usarlo estos días.

  • Por ejemplo, el otro día necesitaba obtener del fichero de log de Tomcat las líneas que contuviesen o bien “SOAP21″ o bien ” – 2 “. Esto sería sencillo de hacer con dos grep, pero yo necesitaba que esas líneas mantuviesen el orden en el que habían aparecido en el fichero, y hacer eso con un grep requiere de una expresión regular bastante más compleja de lo que en realidad es necesario. Además, quería saber en qué número de línea del fichero estaba cada línea buscada. Con awk, fue tan sencillo como esto:
    cat tomcat.log | awk '/SOAP21/{print NR " - " $0} / - 2/{print NR " - "$0}'
  • También necesité, en el mismo fichero, verificar que se cumpliese una secuencia, y concretamente, me valía saber que, dentro del conjunto de líneas que contenían “SOAP21″, las múltiplo de 5 eran idénticas, ya que de esta manera sabía que se habían cumplido todos los pasos. Por lo tanto, necesitaba sacar las líneas que tuviesen “SOAP21″, y dentro de éstas, sólo las que su número de línea fuese múltiplo de 5. Nuevamente, awk te lo pone fácil:
    cat tomcat.log | awk 'BEGIN { nl = 1 } /SOAP21/ { if (nl % 5 == 0) print ; nl++}'
  • En plan más “complicado” (teniendo en cuenta que lo de antes era trivial), hice una pequeña línea para sacar la nota media a partir del archivo html que te devuelve la UPM cuando consultas tu expendiente usando la modalidad “Último estado de cada asignatura” (aunque falla cuando tienes alguna matrícula, pero bueno, eso no es lo importante ahora). El código es el siguiente:
    cat consulta.upm.html | grep "
    /<\/table>/ { d = 0 } { if (d > 0) { if (c == 10) { print ; c = 0 } else c++ } }' | grep
    '>\([1-9][0-9]\|[1-9]\|[1-9]\,[0-9]\{1\}\|[1-9]\,[0-9]\{2\}\)<' | cut -d 1 -f2 -d'>' | cut
    -f1 -d'<' | awk 'BEGIN { t=0.0;n=0; } {print ; t=t+$1 ; n++} END { print "Total " t "
    Asignaturas " n " Media " t/n}'

    Como veis, el primer fragmento de awk hace una selección de líneas, imprimiendo sólo las filas de las tablas que sean múltiplo de 10 (son en las que se encuentran las notas) y que estén contenidas entre una línea que tenga la palabra Obs y el primer final de tabla en html. Una vez obtenidas estas líneas, uso grep para quedarme solo con las que tienen nota y cut para dejar sólo la nota, quitando el resto de elementos html. El segundo fragmento de awk se encarga de ir sumando las notas y el número de asignaturas para imprimir la media.
  • EDITO: iré añadiendo más fantabulosos ejemplos ;-) según me los vaya encontrado.

  • Mi hermano el otro día me preguntó como resolvería un problema y le sugerí que usara awk. El problema consistía en que tenía ficheros (por cierto, de más de 80.000 líneas) con una estructura tal que
    frase1 1
    frase2 5
    ...
    fraseN M

    y quería sumar los números de cada frase. En el caso original tenía la ventaja de que las frases siempre iban en el mismo orden en todos los ficheros, pero la sencillez de awk hace que la solución (que corre a cargo de mi hermano, por cierto) valga para casos que no estén en orden (e incluso que aparezcan frases en algunos ficheros y en otros no). Además, se requería que fuese relativamente rápido, y awk cumplió con las expectativas (la solución previa eran pruebas con scripts más o menos a mano y los resultados se iban por encima de los 10 minutos, frente a los 2 minutos de la solución con awk). El único problema era juntar la salida de los ficheros, pero awk permite trabajar con varios ficheros de entrada de datos (si no, un poquito de bash scripting, for i in *.out ; do cat $i ; done, lo hubiese solucionado). Los ficheros tenían extensión .out, por lo que la solución final es:
    awk 'BEGIN { FS = " ";} { resultados[$1] += $2 } END { for(category in resultados) print category, resultados[category]; } *.out'
    Como veis es sencillo, limpio y eficaz :-D ¡con awk, la suciedad se va en un bang! Aquí además podeis ver algunas cosas más de awk, como los bucles, los array (estilo PHP, sin declaración ni reserva de memoria ni inicialización de datos) y la variable especial FS, que sirve para especificar cómo separar los campos de una línea (aunque en este caso no haga falta porque por defecto es espacio o tabulador).

Y esto es todo por hoy. Huelga decir que en Internet encontrareis cientos de ejemplos y tutoriales, pero yo quería hacer una pequeña introducción con un par de ejemplos más prácticos que los que suelo encontrar (al menos, serían prácticos para mí ;-)). Espero que os sea de utilidad.

Jamie Zawinski dijo

Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems.

Jamie Zawinski, en comp.lang.emacs.

O, traduciendo al español,

Algunas personas, al enfrentarse a un problema, piensan “Ya lo tengo, usaré una expresión regular”. En ese momento, tienen dos problemas.

Cualquier informático da (o debería) dar fé :-D .