Varnish para WordPress como Servicio

¿Tu WordPress va lento? ¿Te gustaría que volase? Pues esta es la idea que he estado planteando desde hace unos días… Hace cosa de un año que comencé a montar blogs con WordPress bajo Varnish. Al principio iba bien pero configurarlo y mantener las máquinas es algo complejo, a parte de que no todo el mundo puede permitirse montar y mantenerlo. Así que, tras muchas vueltas, pruebas, testeo de plugins y demás, he conseguido poder montar un sistema que, de forma sencilla, permita cachear y mantener un WordPress con Varnish.

El sistema es sencillo… sólo hay que subir 2 plugins: uno de ellos es para purgar (limpiar) la caché de Varnish cuando alguien publica algo, comenta, edita… así, cuando el blog cambie, se regenera la caché y los usuarios ven las cosas nuevas y actualizadas; el otro plugin es algo más genérico y hace referencia a la gestión de la IP, ya que al ser un web-proxy siempre devuelve la misma IP y eso genera problemas con el spam y similares.

Una vez configurado esto, lo bueno es que se puede probar antes de ponerlo en producción. Simplemente te cambias la IP de tu fichero de host y compruebas si todo funciona correctamente. Una vez probado, se cambian las DNS del dominio y ya está, todo listo.

Una cosa buena también que tiene este sistema es que, si por lo que sea, el Varnish empezase a hacer e tonto o quieres dejar de usar el servicio, vuelves a poner tus DNS como antes, quitas los plugins y ya está, todo vuelve a la normalidad.

¿Te gustaría probarlo? Pues si te interesa puedes escribirme (si me adelantas el dominio en que lo quieres probar, mejor que mejor) y te escribo con todos los pasos. Por ahora vamos a dar una semana de pruebas a aquellos que lo quieras testear en su sitio (ya sea por fichero de host o en producción) y a partir de ahí valdrá 120 euros/año u 80 euros/semestre.

¿Qué cosas buenas tiene usar este sistema? Primero que tu sitio estará cacheado y que soportará picos de tráfico sin problema; que cuando un robots de búsqueda te visite verá que la web va rápida y te indexará más rápido; por norma general el tráfico SEO aumenta a las 4 semanas de usar este sistema… además, sigues teniendo el control de todo en todo momento.

Y para muestra, un par de pruebas… Las he realizado desde el sitio Web Page test, primero apuntando a la IP del servidor directamente y luego apuntando a la del servidor con Varnish. El sitio desde el que se han hecho las pruebas es París con conexión de Cable.

Enlaces a los resultados de la Prueba Directa y a la Prueba con Varnish.

Como detalle, que no lo he podido capturar al 100%, el sistema hace 2 peticiones, la primera normal, luego refresca y usa la caché del navegador, y luego vuelve a repetir lo mismo. En el caso del acceso duirecto, WordPress ha de generar completamente la página, que tarda aproximadamente unos 2,5 segundos. Luego, en cualquier caso, el refresco es rápido, y tarda muy poco. Cuando estos e hace con Varnish delante, la primera ocasión tarda lo mismo, pero cuando vaciamos la caché del navegador como ya no se genera la página, tarda tan sólo 1,5 segundos.

Directo Varnish
lectura 1 2.575s 2.765s
caché 1 1.238s 0.435s
lectura 2 2.172s 1.416s
caché 2 1.245s 0.315s

En general, como los usuarios navegarán por las versiones de “lectura 2” (la lectura 1 sólo se ejecutará cuando haya contenido nuevo o se vacíe la caché), los datos muestran que el blog carga entre un 60% y un 75% más rápido. Os dejo con algunos otros gráficos:

En estos datos se ven los tiempos de respuesta que han obtenido mejor valoración en las 2 pruebas realizadas…

Acceso directo:

Acceso por Varnish:

Aquí se muestra en una valoración simple los resultados que dan Google Page Speed y Yahoo! YSlow…

Acceso directo:

Acceso por Varnish:

Y finalmente un checklist de todas las peticiones que se han relalizado…

Acceso directo:

Acceso por Varnish:

En fin, creo que es bastante obvio que usar Varnish es una gran ventaja competitiva con respecto a los sitios que no lo tienen…

Otra prueba interesante es hacer un test de estrés. La idea es hacer crecer las peticiones simultáneas al sitio… el test lleva un 50% de visitas desde Dublín (IE) y un 50% de visitas desde Palo Alto (CA, US), hasta las 100 conexiones simultáneas. Las gráficas son bastante clarificadoras…

Enlaces a los resultados de la Prueba Directa y a la Prueba con Varnish. Creo que las gráficas hablan por sí solas…

Tiempos de carga por página:

Clientes 15 31 51 70 85 100
Directo 1.63s 2.71s 3.98s 17.26s 21.18s 26.54s
Varnish 1.27s 1.14s 1.20s 1.28s 1.48s 1.27s

Acceso directo:

Acceso por Varnish:

¿Te gustaría probarlo? Pues si te interesa puedes escribirme (si me adelantas el dominio en que lo quieres probar, mejor que mejor) y te escribo con todos los pasos. Por ahora vamos a dar una semana de pruebas a aquellos que lo quieras testear en su sitio (ya sea por fichero de host o en producción) y a partir de ahí valdrá 120 euros/año u 80 euros/semestre.

Varnish User Group Meeting 5 #VUG5

Varnish Caché es un software muy especial, sobre todo desde que ha conseguido que, como dice su eslogan, las webs “vuelen”. Y es que sin duda una capa intermedia de web-caché que prácticamente no influye en nada en la configuración del sitio es mágico. Ayer tuve la oportunidad de estar en el Varnish User Group Meeting 5 y conocer a parte del equipo de Varnish y conocer otros proyectos y empresas que utilizan este software. Voy a intentar hacer un pequeño resumen de algunas de las charlas que me parecieron más interesantes.

Para comenzar, Poul-Henning Kamp –@bsdphk– (si no me equivoco es el desarrollador jefe del software) explicó algunas ideas que tienen del roadmap hasta 2020, y lo curioso es que casi no explicó nada del propio sistema, sino de cómo van a ser los protocolos de Internet en los próximos años.

En 2006 Varnish simplemente era un web-caché, que permitía la propia caché, el sistema de configuración por VCL y los “baneos” (limpieza de caché desde el sistema de administración). En 2009 se introdujo el “purgado” (limpieza de caché desde fuera del panel) y la implementación de parte del estándar ESI. En 2012 con la versión 3.0 se ha implementado el sistema de VMODs (módulos, plugins… como queráis), soporte a gZip…

¿Qué cosas podría llevar Varnish en las próximas versiones? Pues parece que Virtualización de VCL (por ejemplo, distintos dominios, distintos VCL), buffering del ESI (ahora hay problemas de cabeceras) y posibilidad de soporte de otros protocolos: UNIX sockets, fastcgi, SCTP, HTTP/2.0, SPDY o SSL.

De todo lo que comentó, quizá lo que más me llamó la atención es el tema del HTTP/2.0 (también conocido como HTTPbis). En la última documentación, la información casi se ha duplicado con respecto al RFC2616, lo que significa que en vez de simplificarse se ha complicado muchísimo. hay 3 objetivos básicos en esta nueva versión: Velocidad (pipeling, multiplexion, header compression…), Confianza (privacy, integrity, identity, auth…) y Servicio (sessions…).

Un planteamiento que se ha hecho es que SPDY sea el próximo HTTP 2, pero lo malo de ello es que es un protocolo proporcionado por Google y que para ello hay que seguir la agenda del gigante de Mountain View. Además, el SSL es mandatario… así que lo que ganas por un lado lo pierdes por otro. El objetivo de SPDY es evitar que los proveedores de telecomunicaciones (o sea, el que te da la conexión) sea capaz de saber qué envías o recibes y con quién te comunicas. Otra opción sería separar el transport del semantics, y que el transporte sea por “plugins”; algo rollo HTTP sobre: TCP, SSL, UDP, SPDY, SCTP, ECMA-10… El problema será, a parte de saber qué protocolo implementar, cómo luego se comunicará Varnish con los distintos backends. En el momento en el que se de soporte a protocolos múltiples, se añadirán algunos como soporte para vídeos, etc… aunque por ahora se sigue centrando en HTTP. Aun así, se plantean que los protocolos de streaming tienden a desaparecer.

Otro tema interesante del que se habló es dónde se almacena la información… se habló del uso de disco normal, de SSD, de memoria.. y salió un tema de conversación muy interesante en torno a el uso de Varnish en modo Cluster. En principio la gente está escalando usando múltiples Varnish. Incluso se habló del uso de discos en modo NFS, para tener alta disponibilidad. A la vuelta de París se me vino a la cabeza el porqué no se usa algún sistema tipo Hadoop como almacenamiento… aunque supongo que para eso habría que acabar de adecuar el software. Como dato interesante: Varnish soporta perfectamente la gestión de 10 millones de elementos sin ninguna caída en cuanto al rendimiento.

Otra de las charlas, en este caso de Richard Zuidhof comentó varios temas aunque hubo uno que sí que me gustaría destacar (y que a mi a veces me ha dado algún que otro dolor de cabeza) y es el de los timeouts. Por ejemplo, pusieron algunos ejemplos y mucha gente dio cifras, pero me quedo con un par de ellas:

backend localhost {
	[...]
	.first_byte_timeout = 1s;
	.between_bytes_timeout = 1s;
	[...]
}

Lógicamente, estos ería para peticiones internas a la propia máquina, pero como valores “normales” se pusieron estos:

backend default {
	[...]
	.first_byte_timeout = 180s;
	.between_bytes_timeout = 120s;
	[...]
}

Personalmente yo reduciría mushísimo estos valores, porque tampoco tiene sentido tener estas cifras tan altas… y las dejaría en:

backend default {
	[...]
	.first_byte_timeout = 10s;
	.between_bytes_timeout = 5s;
	[...]
}

Creo que si una página tarda más de 10 segundos en conectar ya debe dar ese timeout y que si entre petición y petición hay más de 5 segundos de diferencia, también ha de “fallar”.

Lasse Karstensen @lkarsten estuvo comentando bastante un tema muy interesante que afecta a SEO y afecta a cosas que leía hace unos días desde Bing / Microsoft, la detección de dispositivos desde Varnish. El objetivo sería tener algo como una cabecera X-UA-Device que mediante un Vary pueda cachear cada una de las páginas resultantes según el dispositivo. Para ello existen un par de herramientas:

Como ejemplos tenemos varios directamente en la documentación sobre detección de dispositivos de Varnish.

Otro que comentó cosas interesantes fue Andreas Plesner, hablando sobre cómo evitar que Varnish pete. No voy a entrar en profundidad, pero se habló del Saint_Mode (y si no recuerdo mal existe el GOD_Mode) además del más conocido Grace_Mode. Otra cosa interesante es comenzar a diferenciar el HIT del PASS del HIT_FOR_PASS. Otro detalle interesante es el de establecer, de forma forzada, un Set-Connection: Close cuando haya conexiones “pipe”.

Uno de los ejemplos prácticos del día lo puso Lionel Touati, responsable de tecnología de Maisons du Monde, un sitio web de comercio electrónico de decoración elementos del hogar. Su sitio web está creado por ellos y cada semana hacen una actualización. Su obsesión por el SEO ahora se enfoca e el Web performance, y para ello han implementado Varnish a un nivel muy profundo. Aún así, tan sólo cachean un 30% de las peticiones. Eso sí, el hecho de reducir el tiempo de carga se ha visto directamente relacionado con el aumento de páginas vistas, como nos enseñó.

Otro que dio una charla muy interesante fue Kacper Wysocki, entusiasmado de la seguridad y que estuvo explicando cómo usar Varnish simplemente como un Web-Firewall, como lo llama él. Seguro que habéis escuchado sobre el mod_security de Apache; pues con el secure.vcl más o menos se trabaja en lo mismo, con la diferencia de que activar y desactivar elementos es muy sencillo. Una herramienta muy interesante para testear el funcionamiento es el OWASP Zed Attack Proxy Project, que incluye ataques prefabricados a distintos software para ver sus vulnerabilidades.

Como comentaba al principio, entre las cosas que lleva Varnish en esta tercera versión ha sido la incorporación de los “Varnish Modules”, los VMODs. Pues Varnish ha lanzado un directorio con algunos módulos que ya se pueden implementar en el sistema. El objetivo es hacer crecer esta lista, sobre todo con la aportación de los códigos de los usuarios.

Y para acabar, un par de sistemas interesantes que vienen de la mano de Opera Software. El primero de ellos es un sistema que estandariza el Accept-Language y otro que trabaja con el GeoIP. Para aquellos proyectos multi idioma y multi país estos ficheros serán básicos a la hora de implementarse en la configuración de la plataforma.

En medio año se llevará a cabo el VUG6, y probablemente sea en Argentina… y si es así, creo que también me acercaré, porque desde Keep It Simple Lab estamos preparando a montar varias ideas trabajando sobre Varnish y que tienen que ver con WordPress, Magento y otros proyectos que harán que, como bien dice el eslogan de Varnish, tu sitio web vuele. dar las gracias a Rubén Romero @ruben_varnish por la organización y a la espera de que en un futuro (espero que no muy lejano) participen en los eventos WebPerf de España.

Y hasta aquí la visita a París, ciudad que no pisaba desde hacía unos 18 años… cuando un chaval de 8º de EGB hacía el viaje de fin de curso a la ciudad.

Guía de HTML Data

En los últimos años microformatos, microformatos-2, RDFa o microdatos se han convertido en elementos básicos de la construcción del HTML siempre que hemos querido darle información semántica a las máquinas, a los robots de búsqueda. Pero ¿estás usándolos realmente de forma correcta?

La respuesta a esta pregunta siempre la hemos de buscar en la información que el organismo de crear los estándares de desarrollo web nos ofrece, y para esto existe la HTML data Guide donde nos encontramos con un resumen bastante interesante de su funcionamiento.

Antes de nada, poner los enlaces a las páginas oficiales de cada uno de estos lenguajes de marcas que os he comentado al inicio:

Todos estos elementos tienen una cosa en común, y es que permiten extraer información de páginas HTML de forma sencilla, y me atrevería a decir que información inteligente y semántica.

En la actualidad, como vengo comentando, existen tres sintaxis principales:

Microformatos

Los microformatos usan @class, @rel y otros atributos para codificar datos en HTML. Además pueden usarse con cualquier lenguaje de marcas que use atributos @class. Hsta el momento los microformatos tenían varios vocabularios para hacer diferentes cosas, pero con los Microformatos 2 esto se ha estandarizado a un sistema único de proceso.

RDFa

El RDFa reutiliza código HTML existente como @href y @rel añadiéndole pequeñas partes más que permiten extraer información (como ya ocurre con el RDF). Estaba pensado originalmente para el XHTML 1.1 y es compatible con HTML 5 y SVG.

microdatos

Los microdatos añaden atributos al HTML 5, de forma que cualquier elemento pueda tener una serie de propiedades y valores. Estos están diseñados para añadir información detallada que pueda ser procesada por los usuarios.

NOTA 1: Los microdatos SÓLO funcionan con HTML 5, por lo que aunque pongas cosas como Schema, si tu web no es HTML 5 buscadores como Bing o Google no “interpretarán” la información que les has dado porque no cumplen con el estándar.

NOTA 2: Bing tiene la herramienta Markup Validator, Google el Rich Snippets Testing Tool y Yandex el Microformat validator para verificar la mayoría de estas sistaxis. Además existen herramientas como el RDFa Validator o el Living Validator, este último aceptando en principio todos los formatos y sistemas.

La forma de aplicar estos sistemas es triple también. Se puede hacer mediante la inclusión en la cabecera de la página de metadatos, como por ejemplo en elemento link con un rel=”alternate”:

<link rel="alternate" type="text/calendar" value="calendar.ics">

La otra opción es la de incrustar código dentro del propio código HTML, aún en la cabecera. Para ello se podrían usar elementos como JSON o Turtle, algo similar a esto:

<script type="text/turtle">
  @prefix foaf: <http://xmlns.com/foaf/0.1/> .
  @prefix gr: <http://purl.org/goodrelations/v1#> .
  @prefix vcard: <http://www.w3.org/2006/vcard/ns#> .
  @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
  <#company> gr:hasPOS <#store> .
  <#store> a gr:Location ;
    gr:name "Hair Masters" ;
    vcard:adr [
      a vcard:Address ;
      vcard:country-name "USA" ;
      vcard:locality "Sebastpol" ;
      vcard:postal-code "95472" ;
      vcard:street-address "6980 Mckinley Ave" ;
    ] ;
    foaf:page <> ;
    .
</script>

Para acabar, quizá la actualmente más conocida, es la de incrustar meta información en el cuerpo de la página, a través de los atributos custom data válidos sólo en HTML 5.

<div class="spaceship" data-ship-id="92432"
     data-weapons="laser 2" data-shields="50%"
     data-x="30" data-y="10" data-z="90">
 <button class="fire"
      onclick="spaceships[this.parentNode.dataset.shipId].fire()"> Fire
 </button>
</div>

Para acabar, un poco de terminología, para entender bien las palabras que debemos usar cuando hablemos de esto:

  • Formato es la combinación de Sintaxis, Tipos, Propiedades de una o más Vocabularios.
  • Sintaxis son las distintas formas de organizar la información. En este caso hemos hablado de microformatos, RDFa y microdatos.
  • Vocabulario es cada uno de los conjuntos que permite cada sintaxis formado por entidades. Por ejemplo el microdato “producto” o el microformato “hcard”.
  • Entidad es cada uno de los pequeños elementos por las que se forma un Vocabulario. Por ejemplo el nombre de una persona, una dirección… Cada entidad tiene uno o más Tipos de datos, y estos tipos de datos tienen una serie de Propiedades con sus respectivos Valores.

A la hora de publicar información lo más sencillo es publicar y mantener tan sólo un tipo de vocabulario por página. En caso de estar utilizando HTML 5 es más que recomendable usar los microdatos, ya que son los que permiten mayor extensibilidad; en cualquier otro dato los microformatos son la opción más adecuada. El RDFa prácticamente no se utiliza.

NOTA 3: Por ahora mi experiencia personal es que Google sólo lee el primero de los vocabularios que se incluyen en una página. Hay que recordar que muchas entidades se pueden anidar, por lo que es mejor utilizar el vocabulario principal y no usar varios.

Aunque el estándar permite el cruce de distintas sintaxis en una página, hoy en día, teniendo en cuenta que la mayoría de webmasters que publicarán vocabularios en sus páginas lo hacen por un tema puro y duro de SEO, casi es mejor limitarse a uno de ellos que, como decía antes, si se dispone de HTML 5 en el sitio, es el óptimo.

Una gran diferencia entre microformatos + RDFa y los microdatos es que las propiedades de cada entidad están bastante establecidas; esto significa que los microformatos no son extensibles y han de adaptarse al 100% a lo que el estándar permite, pero, en contra, los microdatos pueden seguir el estándar y pueden tener valores no estándar, lo que permite su escalabilidad de forma infinita.

En cambio, hay una cosa en contra de los microdatos, y es que es bastante más difícil el uso de los multi idiomas en la información. Los microformatos permiten el uso de @lang como una propiedad, algo que los microdatos no permiten, por lo que se complica el uso.

Otra cosa a tener en cuenta es el diseño, el visual. Para una ficha de persona, por ejemplo, poner el nombre de la persona en negrita, en las tres sintaxis tendríamos un código tal que este:

microformatos:

.hcard .n { font-weight: bold; }

RDFa:

[typeof~="foaf:Person"] [property~="foaf:name"]

microdata:

[itemtype~="http://microformats.org/profile/hcard"] [itemprop~="n"]

Esto hace que, a nivel de uso de los CSS los microformatos sean una herramienta mucho más sencilla que el resto. Claro está, se pueden incluir clases y similares, pero sería información añadida que sólo sería útil en diseño y no en código fuente.

A la hora de gestionar fechas y horas, si queremos mezclar información y hacerla 100% compatible entre distintos formatos podríamos usar algo parecido a esto (que mezcla HTML 5 con otros elementos, haciéndolo completamente compatible; hay que tener en cuenta que el elemento abbr puede usarse para patrones de fechas).

<time itemprop="dtstart" property="startDate" content="2016-04-21T20:00:00">
  <abbr class="dtstart" title="2016-04-21T20:00:00">
    Thu, 04/21/16 8:00 p.m.
  </abbr>
</time>

En lo que respecta a relaciones de enlaces, HTML 5 incluye bastantes elementos @rel que son comprensibles, pero que no son compatibles con otros sistemas como RDFa. Lo que sí es compatible es el uso del @vocab, donde se informa del tipo de contenido que llevaría el enlace. Con esto podríamos conseguir algo similar a:

<a vocab="http://purl.org/dc/terms/"
   rel="date" href="http://reference.data.gov.uk/id/day/2011-11-15">
15th November 2011</a>

Con esto conseguiríamos que la relación del enlace fuera de tipo dc:date, es decir, que es una fecha, (basándonos en la información Dublin Core).

A la hora de publicar contenido (o información) incrustado en el HTML debemos tener muy presente que las buenas prácticas imperan sobre cualquier cosa, ya que si el lenguaje de marcas es incorrecto la extracción de información se vuelve muy compleja. Por eso hay que tener muy presente el uso de un HTML válido. Todas las sintáxis necesitan de una estructura, ya que esto se basa en los datos estructurados, así que es básico cumplir con los estándares de HTML.

Como primera recomendación, es casi básico utilizar sistemas de lectura que permitan HTML 5, es decir, navegadores de última generación. Varios ejemplos son que, Firefox (y otros) no es capaz de procesar los elementos que no se pueden dejar dentro de una tabla y los sacan fuera de ella. Incluso, hay navegadores antiguos que los elementos meta o rel no pueden ser procesados en el body y son “movidos” al head, con las consecuencias de errores de proceso que ello genera.

Otra buena práctica es la de definir la licencia de uso de dicha información. Al fin y al cabo la información que se introduce es pública pero no por ello tiene porqué permitirse la reutilización de la misma. Así que, ya que todas las sintaxis lo permiten, es más que recomendable informar de la licencia de uso.

A la hora de procesar la información que nos ofrece el HTML mediante cualquiera de la sintaxis debemos tener en cuenta que hay dos formas principales de procesarse. La primera de ellas hace referencia a los microformatos 2 y a los microdatos. En ambos casos la información puede procesarse como JSON lo que permite un manejo muy sencillo de la información estructurada. En cambio, el RDFa puede expandise en múltiples opciones. Entre ellas la más habitual es la de convertirlo a RDF/XML o a Turtle, aunque también se podría llegar a extraer vía SPARQL o RDFa API.

Y si no encuentras tu vocabulario… ¿se pueden crear o proponer? Pues la respuesta es simple: sí. Aunque hay varias formas de llegar a hacer propuestas y a distintos niveles. Por ejemplo, existe una página en la que se detalla cómo proponer un microformato, el W3C tiene su Semantic Web Interest Group para crear elementos ya más oficiales e incluso el grupo de Schema (en el que participan los principales motores de búsqueda) tiene el Extension Mechanism en el que no sólo se puede crear un nuevo schema, sino que se pueden extender los actuales, y si mucha gente lo adopta el propio sistema lo tomaría para crear el estándar. En cualquier caso, y mirando hacia el futuro, si vas a crear algo, mi recomendación es que te bases en el estándar de microdata del W3C, responsable del cuál, además, es Ian Hickson (trabajador de Google).

Y en principio todo esto es lo que hay que saber sobre el tratamiento y la incrustación de datos dentro del HTML. Por supuesto no he tratado en detalle ninguno de los vocabularios, pero eso ya depende de cada proyecto y desarrollador (e incluso usuario). Lo que sí que voy a decirte es que, si tienes información estructurada, exista ya o no un sistema estándar, asímate a utilizar el que hay y sino créatelo tú mismo siguiendo las bases que existen.

Splunk Live 2012 Barcelona

Esta mañana he podido asistir al primer evento oficial de Splunk en España, de la mano de OpenS3 en Barcelona y como me ha parecido interesante algunas de las cosas que se han comentado, os las dejo.

Splunk comenzó en 2004 en San Francisco y tiene más de 400 empleados en 8 países. Las principales oficinas están en Hong Kong y Londres. Tienen más de 3500 clientes de 70 países, de los cuales 48 están en el Fortune 100.

Hay muchos casos en los que Splunk está analizando más de 10 TB diarios de información. Algunas empresas como Facebook, eBay, Linkedin, Sony, BBC, Symantec y otros están utilizando esta herramienta. Con sistemas similares a MapReduce no hay limitación en cuanto a la escalabilidad de la plataforma. Cisco además de ser un cliente es un partner en cuanto en algunos casos integran en sus sistemas Splunk. Según Cisco, Splunk es el único software capaz de interpretar cualquiera de los logs que se generan en las máquinas de Cisco, y no como en otros casos que tienen muchos pequeños productos que leen una parte de la información.

Splunk además es una gran herramienta de seguridad, ya que es pro activa en analizar comportamiento extraños en los logs. Por ejemplo, si estás recibiendo un ataque desde una serie de direcciones rusas, sería capaz de detectar qué máquina o qué servicio es el que está enviando o recibiendo esta información. A parte de logs, es capaz de recibir información de bases de datos, GPS, registros de sistema, cualquier elemento que se pueda concebir como “datos IT”. Esta información, además de ser útil para los técnicos, puede ser útil para marketing o seguridad.

Otra de las funcionalidades interesantes de Splunk es la posibilidad de ser utilizado como sistema de Web Analytics, aunque es una pequeña parte del sistema, es capaz de analizar cualquiera de los elementos: páginas, vídeos, imágenes…

Splunk se divide en 3 partes: Collectors, Indexers y Search Heads (que es la web donde se ve la información). Se puede escalar horizontalmente, tienen alta disponibilidad y podría recoger unos 25 GB diarios. Cada máquina podría ser un quad-core con 8GB de RAM. El despliegue es bastante rápido y es capaz de usarse independientemente de cada lugar. Los Indexer pueden estar geolocalizados y el Search Head cercano a donde los usuarios lo van a utilizar.

El sistema es capaz de interpretar expresiones regulares para los distintos elementos que pueden encontrarse en los logs, de forma que es capaz de interpretar cualquier tipo de fichero. Es capaz de monitorizar el sistema de ficheros, registros del sistema operativo, control de hypervisores de máquinas virtuales, aplicaciones web, tablas o esquemas en bases de datos, configuraciones de red…

Splunk aparece como base como un buscador al estilo de Google en el que puedes realizar cualquier tipo de datos (buscar una IP, una dirección URL…) además de permitir generar informes personalizados en base a la información recogida. Además se puede hacer seguimiento de transacciones. Un ejemplo podría ser que un sitio web genere un identificador de una venta, se cruzan datos con que se haya enviado un correo avisando de la venta al usuario, y finalmente que el paquete (logística) se haya enviado.

Splunk tiene un sistema de geolocalización de direcciones IP, de forma que se podría analizar de una forma muy sencilla y mostrar o geolocalizar las visitas con mucho detalle (dependiendo incluso de qué sea, con datos de coordenadas GPS).

Existe un repositorio de paneles ya creados que analizan directamente los logs o datos. Muchas de estas extensiones están realizados directamente por la gente de Splunk aunque hay una gran comunidad detrás generando estos paneles.

Evento Web Performance

Gentes de Barcelona y Madrid, ¡preparaos! porque llegan los eventos WebPerf a España.

Los que me conocéis sabéis que llevo trabajando desde hace bastante en este proyecto, en recuperar mi faceta de “montar eventos”, aunque esta vez no quiero montar un macro congreso como en otras ocasiones, sino que quiero algo más reducido y sobre todo de profesionales a profesionales del sector.

WebPerf está concebido como un evento formativo en el que más o menos en 2 horas podamos tratar algún tema concreto, de bajo o alto nivel, con un ponente que de una charla de 1 hora exponiendo su punto de vista y el resto del tiempo plantear dudas, sugerencias y que cualquiera pueda salir a la palestra a explicar lo que quiera.

Esto significa que el evento está dirigido a aquellos que se dedican, tecnológicamente hablando, en cuerpo y alma a mejorar los sitios web de Internet, ya sea mejorando el código fuente de una página concreta hasta montando la infraestructura de los centros de datos. Repito, para los que habéis preguntado ya: es un evento de tecnología, de esos en los que se dicen palabras raras.

El funcionamiento del evento será mediante una lista de correo a la que se puede apuntar cualquiera desde la que se propondrán temas y se puede hablar con el resto de asistentes o de los apuntados. En esta lista se irán proponiendo temas a modo de Call for Papers para ir sacando ponentes que quieran tratarlos.

El lugar elegido será el de La Salle, que nos ceden amablemente un aula con todo lo necesario para dar esa “clase” en la que podamos aprender. Por ahora comenzaremos en Barcelona, en abril y junio, y a partir de septiembre iremos intercalando Barcelona y Madrid.

¿Temas de los que se hablarán? Pues para comenzar en esta primera ocasión, y como avanzadilla, es probable que hagamos algo bastante accesible a todos, como es el Web Performance para WordPress, intentando ver el asunto desde el punto de vista de los plugins y hacer tunning del propio WordPress, y por otro del de montar una infraestructura como si fuera para una red de blogs, que soporte tranquilamente millones de visitas sin problema, al menos coste.

Pero esto es sólo el principio, más adelante trataremos temas como mejoras de software de comercio electrónico (como Magento o Prestashop), experiencias con Apache 2.4, cómo escalar MySQL, el uso de web-proxy como nginx o Varnish, elementos olvidados como la conectividad y mejoras como SPDY…

Y ahora unos pocos enlaces para poder estar pendiente de todo:

  • WebPerf: La web donde habrá información propia del evento. Tiene secciones para Barcelona y Madrid.
  • WebPerf feed: Feed de noticias y artículos del sector (las mismas que aparecen en la cuenta de twitter).
  • @WebPerfES: Cuenta de twitter con noticias y artículos del sector del Web Performance.
  • @WebPerfBCN: Cuenta de twitter con información y seguimiento del evento de Barcelona.
  • @WebPerfMAD: Cuenta de twitter con información y seguimiento del evento de Madrid.

Así que si eres del mundillo de Internet, de los que toca la parte más técnica, un ISP, desarrollador, administrador de sistemas o similar, prepárate, que ya tenemos un evento en el que reunirnos y salir de la cueva 😉 Apúntate a la lista de correo donde podrás estar informado o hacer consultas técnicas de las que tengas dudas.

Search Congress Barcelona 2012

Estos días se está celebrando el Search Congress en Barcelona y una vez más me toca dar una charla. Este año es de Web Performance Optimization, y aunque es de sólo 30 minutos, creo que a los que no hayan escuchando nunca del tema les será mínimamente útil.

Hace ya un par años, en el Search Congress de Bilbao presenté algo que aún no llamaba WPO sino “infraestructura SEO” en el que di los primeros pasos a tratar sobre todo este mundillo. Esta vez no he tenido las 3 horas que tuve la otra vez, sólo 30 minutos, así que como dicen por aquí “us faig cinc cèntims”.

Os dejo la presentación para que la descarguéis si os interesa, muy en la línea de seguir siendo un SEO Open Source.