|

WebSockets en HTML5

HTML5 introduce una característica que puede mejorar sustancialmente las aplicaciones web, los WebSockets, los cuales permite crear un canal de comunicación bi-direccional entre el cliente y el servidor, solucionando los problemas que presenta Ajax o Comet. El ancho de banda ahorrado tiene una proporción de 500:1 y una latencia de 3:1, resultados increíbles que hacen que los de Google anden muy interesandos en esta tecnología (el ahorro en aplicaciones como GMail puede ser considerable).

Por ahora sólo funciona en Google, pero un código de ejemplo sería el siguiente:

if ("WebSocket" in window) {
  var ws = new WebSocket("ws://websockets.org:8787"); //this service bounces messages back
  ws.onopen = function() {
    // Web Socket is connected. You can send data by send() method.
    ws.send("message to send"); 
  };
  ws.onmessage = function (evt) { var received_msg = evt.data; alert(evt.data);  };
  ws.onclose = function() { /* websocket is closed.*/alert("WebSocket Closed!"); };
}else{
  // the browser doesn't support WebSocket.
  alert("Websocket is not supported in your browser");
}

HTML5 Web Sockets: A Quantum Leap in Scalability for the Web

Vía / DZone

|

Escalar aplicaciones web usando HMVC

Hierarchical-Model-View-Controller (HMVC) es una variante del MVC que se forma mediante una colección de estos, siendo cada MVC independiente de los otros, y siendo un aspecto importante la reutilización de código, por lo que la localización física de los MVC no es importante. El HMVC es muy efectivo a la hora de testear módulos de la aplicación independientes, y una buena opción para escalar nuestra aplicación.

El tutorial nos muestra cómo usar Kohana para llevar a cabo una aplicación que implemente HMVC. Está claro que una aplicación así puede ser algo más difícil de diseñar y que no siempre puede que necesitemos este grado de escalabilidad.

Scaling Web Applications with HMVC

Diferentes técnicas de cacheado

Otro interesante artículo sobre caché y los distintos modos de poder llevarlo a cabo. Para aquellos que quieran añadir caché a su sistema y ahorrar recursos y no sepan qué hacer, puede venirles muy bien este wiki y el listado de tipos de cache que hay:

  • Caching Proxy Servers
  • Content Delivery Networks
  • Cachear páginas completas
  • Cachear páginas parciales
  • Cabeceras HTTP
  • Memoria compartida (memcache, APC)
  • Cache en la BD

Web application/Caching

Vía / DZone

HAProxy: proxy para mejorar el rendimiento

HAProxy es un proxy gratuito, con balanceo de carga y que soporta decenas de miles de peticiones. Además de tener un gran rendimiento, permite tener un control de concurrencia, esencial cuando tenemos demasiadas peticiones que nuestro sistema no puede soportar, y en vez de saturar el sistema y dar un mal servicio a todo el mundo, podemos limitar el número de peticiones para que al menos una parte de los usuarios sí reciban el servicio adecuado.

HAProxy

Vía / SaaS Interrupted

Consejos para desarrollar en la nube

Aunque no soy muy fan de la moda del cloud computing, quizás porque se habla de ello muchas veces un tanto a la ligera, si que creo que desarrollar aplicaciones en arquitecturas basadas en la nube es algo que en el futuro tendremos que realizar (más basado en hosting que en servicios). Por ello estos consejos pueden ser interesantes:

  • Las máquinas son igualmente inseguros: es por ello que tampoco merece la pena gastar más medios en máquinas más críticas como la BD. Toda máquina falla, por lo que es mejor diseñar la arquitectura teniendo esto en mente para poder recuperarnos de una caída más facilmente.
  • Una aplicación en la nube depende absolutamente de la red y el IO, por lo que no es buena idea tenerlos “físicamente” muy lejos. Esto es uno de los motivos por los que yo, personalmente, no creo que tenga mucho éxito el concepto nube pensado como aplicación en Google y BD en Amazon (o parecido), algo que muchos se dedican a “vendernos”.
  • La red no es fiable, por lo que es conveniente tener sistemas de monitorización para saber qué ocurre en las máquinas y si tienen accesos unas a otras

El post original explica mejor cada punto y ofrece otros consejos más, que recomiendo leer.

Designing applications for cloud deployment

oEmbed: formato para URLs de contenido EMBED

Bueno, el título es algo difícil de entender, pero el concepto es fácil, oEmbed es un formato para devolver información sobre URLs que muestran contenido incrustable: imágenes, vídeos, …

Por ejemplo para Flickr sería:

http://www.flickr.com/services/oembed/?url=http%3A//www.flickr.com/photos/bees/2341623661/

Y el resultado en formato JSON sería:

{
  "version": "1.0",
  "type": "photo",
  "width": 240,
  "height": 160,
  "title": "ZB8T0193",
  "url": "http://farm4.static.flickr.com/3123/2341623661_7c99f48bbf_m.jpg",
  "author_name": "Bees",
  "author_url": "http://www.flickr.com/photos/bees/",
  "provider_name": "Flickr",
  "provider_url": "http://www.flickr.com/"
}

Existen librerías PHP y jQuery que funcionan con proxy para obtener la información.

Learning oEmbed: Convert Links Into Embedded Content

Estadísticas de uso de Twitter

El otro día me dio por pensar cuantos updates debería tener Twitter cada segundo viendo el número de actualizaciones que había por lo de #manifiesto. Para intentar calcularlo creé un script que cada 10 minutos escribiera un tweet en una cuenta guarra de Twitter. Guardé los datos en una BD de SQLite para luego trabajar con los datos obtenidos.

twitter_t.png

Pues los datos que obtuve durante 1 semana es que cada 10 minutos hay una media de 230.000 updates, cada segundo una media de 380 updates, cada hora 1.380.000 updates. Incluso se puede ver una caída en el servicio.

W2W: la web vista desde el P2P

Aviso: este post es simplemente una idea que se me ha ocurrido y que quería compartir, posiblemente no digo más que tonterías, pero bueno, quizás mis tonterías puedan tener algo de sentido común.

Estaba leyendo un post de High Scalability acerca de cómo construir web altamente escalables. El artículo, entre otras muchas cosas habla sobre la posibilidad de crear una red social que tenga la capacidad de soportar miles de millones de usuarios.

Esta magnitud de usuarios puede parecer futurista, pero los datos que aporta sobre Facebook y el crecimiento en número de conexiones a nivel mundial, hacen que estos datos puedan ser posibles en unos cuantos años:

[…] Para hacer este mágico trabajo, Facebook gasta cientos de millones de dólares en datacenters, tienen más de 30.000 servidores, 300 millones de usuarios activos, 80.000 millones de fotografías, sirven 600.000 fotos por segundo, tienen 28TB de caché, generan 25TB de logs por día y su caché sirve 120 millones de queries cada segundo.

A mi estos números me asustan, no sólo por la cantidad en sí de todo: servidores, fotos, queries, … sino porque si por algún casual alguna vez llego a estar metido en un proyecto de esta envergadura no sé si seré capaz de estar a la altura.

Pero si Facebook da miedo, la gente de Google son de otro planeta:

El sistema que Google está construyendo se llama Spanner, La meta de Spanner es soportar 10 millones de servidores, 1013 directorios, 1018 bytes de almacenamiento, extenderlo entre cientos y miles de localizaciones al rededor del mundo para aguantar 109 clientes.

El problema de las redes sociales es que los datos son muy activos: dependen de los usuarios y sus “amigos”, y al estar los usuarios siempre activos, los datos son escasamente cacheables y su recuperación altamente problematica. Si a esto le sumamos la cantidad de usuarios que puede llegar a tener una red social exitosa, hace que me plantee lo siguiente: ¿vamos por el buen camino?

Últimamente se habla mucho de la nube o el cloud computing, pero el planteamiento que a veces se plantea para mí no es el más correcto: desperdigar mi aplicación por Internet (mi aplicación en mi servidor, la BD en Google y las imagenes en Amazon). Yo no estoy en contra de la nube, ni mucho menos, pero quizás en vez del planteamiento guay2.0 que a veces se le da, se podría replantear de distinta forma: el P2P. ¿Por qué es necesario que toda mi información, amigos, fotos y vicios estén en Facebook si no tengo necesidad de ello? En Facebook hay 300 millones de usuarios activos y yo tengo 100 amigos (bueno, yo no tengo ninguno porque no uso Facebook, pero esta es otra historia), eso es el 3×10-5% de la capacidad de Facebook. ¿De verdad necesito Facebook?.

¿Qué idea absurda planteo? La comunicación e intercambio de información entre webs y no entre usuarios. Es decir, yo tengo mis datos en un servicio, y este servicio comparte los datos con un protocolo parecido al P2P (el W2W) con otros servicios (ya sea el mismo u otros distintos). El servicio puede ser Facebook, Twitter, mi propio servidor o blog, una aplicación que tengo en el ordenador conectado todo el día, mi móvil de ultimísima generación, el Kindle, el netbook o una web genérica que se encarga de almacenar mis datos y fotos para que esté siempre online. Cuando yo me conecto a mi servicio y quiero ver lo que han escrito mis amigos o ver sus fotos, mi servicio lee mi lista de amigos (desperdigados en cientos de servicios) y accede a los servicios de cada amigo para recuperar la información. ¿Qué posibilidades ofrece el P2P? que si los datos no los tengo disponibles, se puedan recuperar de otro cliente. En el W2W sería igual, si mis datos no están disponibles porque mi servicio está caído, que se puedan recuperar mis datos de mis amigos, siempre que los permisos lo permitan (ambos son amigos míos o mi perfil es público).

w2w.png

¿Qué se gana con el W2W?

  • No tengo que darme de alta en Facebook porque tenga un amigo que está registrado y es allí donde comparte sus fotos, mi servicio se conectará a Facebook para recuperar sus fotos.
  • No hay necesidad de grandes aplicaciones con necesidad de soluciones drásticas de escalabilidad porque la información se reparte en muchos nodos/servicios.
  • Puedo seguir a mis amigos de Twitter desde otro servicio de microbloggin que me guste más
  • No hay necesidad de registrarse en cientos de aplicaciones para poder estar conectados con todo el mundo
  • Sería algo abierto y distribuido

Quizás a muchos les chirríe esta idea, sobre todo ahora que parece que el futuro está en tenerlo todo en la web, pero viendo la situación actual, los cientos de millones de dólares gastados en datacenters, los problemas de rendimiento de Twitter, los cambios de políticas de privacidad de Facebook, y otras historias, creo que mi idea, a parte de absurda, puede tener algo de futuro.

Aunque el término W2W es algo que me acabo de inventar, no sé si a alguien se le ocurrió lo mismo antes que a mi, no pretendo ser innovador ni original, así que si a alguien conoce algún post que diga lo mismo, por favor que me lo envíe.

Por cierto, interesante web que plantea algo similar para crawlear webs: 80legs.