Tag: ActiveMQ
API stompCLI gestor PHP de conexiones Synchronous-Asynchronous
by admin on Apr.07, 2009, under PHP, Programacion, Tecnologia
Por medio del podcast de DConstruct2008, inicio la curiosidad por las API´s para conexiones Asynchrounous. Para poder interactuar con varios servicios sin necesidad de esperar las respuestas.
De esta manera evitas algunos errores:
- La sobrecarga de peticiones a tus API´s, al servidor web y sobre todo rendimiento de proceso de CPU/memoria de tu equipo o servidor virtual.
- Perdida de comunicación, que genera errores de conectividad para los procesos internos del código.
- Incremento del tráfico en tus puertos de red.
Esto por listar las más obvias. Para este proyecto hay más desarrollo en los API´s de ActiveMQ bajo Java, donde puedes encontrar más información que en la librería echa para PHP.
Lamentablemente no hay muchas métricas en la documentación de stomp cli, pero encontré este reporte en el sitio de FuseSource.
Para que puede servir:
En nuestro del proyecto de FronteraEstates, qué es un portal inmobiliario para Latinos e Hispanos. Estamos coordinando algunos servicios externos de API´s de socialmedia.
Queremos integrar flickr, tweeter y un servicio para identidad digital como Facebook Connect y OpenSocial, todo lo estamos manejando de manera sincronizada, dado que asi lo tenemos en nuestras estaciones de trabajo. Pero a la hora de subirlas al servidor de desarrollo, tenemos ciertos servicios que varían por la naturaleza de nuestro hospedaje. Los resultados de la saturación de recursos se pueden identificar de la siguiente manera:
- Que se llene la memoria del proveedor (nuestro servidor).
- Negación de peticiones para conectarse.
- Que se sature la memoria del cliente.
- Acumulación de peticiones en el buffer.
- Que se agoten las respuestas a peticiones.
Las razones para que esto suceda pueden relacionarse a:
- Red. En nuestra estación de trabajo recibimos el ancho de banda completa, pero dentro de un CPD hay problemas de conectividad, ya sea por latencia del cableado, problemas con puertos de switches/routers/VLAN´s y un largo etc. Problemas que ocurren diariamente dentro de un datacenter.
- Hardware. Puede que la tarjeta de red del servidor pete o se dañe por cualquier razón. Que la memoria RAM se desgaste o simplemente que otro servicio necesite más memoria y nuestro servidor se vea afectada en su capacidad de procesamiento. Esto es normal por el uso del equipo y a saber si estamos en HW nuevo o de segunda mano. Tanto para nuestro servidor, como el equipo del cliente.
- Programación. Uso incorrecto por parte de la lógica de programación de nuestra aplicación. Esto lo asumimos por que, como todos ustedes siempre estamos aprendiendo cosas nuevas e implementando lo que es viable para nuestro proyecto y no puedes evitar cometer errores.
Estos factores influyen en la cola de peticiones externas a nuestro servidor y si manejamos una conectividad asincrona, permites una mayor ventana para la respuesta al llamado de nuestra API. Por otra parte esta todo lo relacionado a la seguridad, aunque la mayoría de los servicios que ofrecen cuentan con maneras de gestionar privilegios y sistemas de autenticar.
Dentro del API tenemos una configuración relacionada a como interpretar cada petición:
CLIENT_ACKNOWLEDGE, este indica que se debe esperar al cliente para que confirme su respuesta y el resultado es un servicio lento, pero seguro de cada transacción que ejecuta – en mi opinión va contraría a la naturaleza de las conexiones por medio de Internet.
AUTO_ACKNOWLEDGE, envía y gestiona un paquete únicamente por petición, esto da también seguridad en la respuesta, sobrecargando el sistema si no se tienen recursos necesarios.
DUPS_OK_ACKNOWLEDGE, por último tenemos esta configuración que permite enviar varias respuestas y recibir varias confirmaciones, lo cual puede saturar el uso del ancho de banda.
Como todo en programación hay sus pros y contras a cada configuración, la decisión debe ir de la mano de nuestra topología de red, la manera que se han programado los procesos externos y cálculos internos de nuestra aplicación web; así mismo tomar en cuenta las características del equipo que dará este servicio y la posible configuración de los equipos clientes (lo cual en Internet es imposible).
Espero cumplir con mi promesa de un post más técnico.
Un saludo a tod@s.