ONO: Cuando un cliente no es un cliente

ono

Soy un cliente de que lleva unos 5-6 años sin problemas, ahora tengo TV/Telefono/Internet 100MB, Internet Móvil…

Ultimamente solo tengo problemas, los cortes de la conexión a Internet los considero hasta asumibles, el que considero más grave es el sentirme defraudado y “estafado” (es duro el término pero es como me siento).

Hace unos días me han llamado de ONO para que me pasase a su servicio móvil, tras explicarles que apenas uso el móvil, al final me ofreciero un HTC Wildfire S, y una tarifa a la que añadimos un extra de datos (para Internet).

Hoy hacen la portabilidad y me llega el teléfono, un LG. Llamo al SAT para indicar que me han enviado un teléfono equivocado, abren una incidencia. [Leer más...]

El extraño caso de los rankings

comparativa

Está más que visto que los más grandes ningunean a los pequeños, pero eso no quita que hay momentos en los que lo hacen dando información falsa y un enlace a la verdadera.

Aquí tenemos un buen ejemplo:

La revista Computer Hoy sacó un ranking sobre ‘tiendas online de informática’, cual ha sido mi sorpresa al ver que en el top 5 de esta lista, estaban TPO Informática (el proyecto de unos emprendedores y amigos) junto con Redcoon.

La gran sorpresa estaba en que estaban en el TOP 5, entre tiendas online que pertenecen a grandes corporaciones, algo que no es malo, pero si es muy bueno que los pequeños se codeen con los grandes. [Leer más...]

Aplicaciones Facebook sobre SSL

mensaje https facebook

Hace unos días Facebook ha empezado a mostrar mensajes de error cuando se accedía a aplicaciones desde https, estando disponible para los desarrolladores, en la configuración de la aplicación, dos nuevos campos, para indicar las urls seguras (sobre https).

Para evitar esto debemos, claramente, añadir soporte https a nuestra aplicación, algo que si bien es sencillo, nos dará más que un quebradero de cabeza. Esto se debe a que nos encontraremos con los nuevos y vitales “bugs” con los que Facebook nos premia a todos los desarrolladores. [Leer más...]

Optimizar las aplicaciones de Facebook más allá del código

Red NetLab

El desarrollo de aplicaciones para Facebook nos requiere una especial optimización de estas para que funcionen en base a dos premisas muy importantes: Seguridad y rapidez.

La rapidez depende de muchos factores, desde la optimización del código hasta la plataforma sobre la que se ejecuta esta, es por esto último que todas las aplicaciones que estamos haciendo son ejecutados con varios servidores con funciones muy específicas.

- Balanceador de carga: Con una conexión a Internet de 100MB/s con un nginx para esta función.
- Servidores de Aplicaciones: Todos son replicas que se crean bajo demanda, permitiendo siempre dar una calidad de servicio óptima independientemente de la carga.
- Servidores de Datos: Los datos están centralizados en estos servidores, que también están replicados. Los datos están, dependiendo de la aplicación en diferentes servidores de bases de datos: SQL (MySQL, PostgreSQL), noSQL ( MongoDB, Membase ).

Las aplicaciones utilizan además un sistema optimizado de caché basado en un sistema de varios nodos de Memcache, reduciendo la carga de consultas a base de datos y a el API de Facebook.

La conectividad es también muy importante, de ahí que la red de Servidores de Aplicaciones tiene una conexión de 100MB/s a internet sólo para acceder a la API de Facebook, y la conectividad interna de todo el ecosistema es con una red GigaEthernet.

Las copias de seguridad se hacen con otra conexión de 100MB al servicio S3 de Amazon.

Evitando de esta forma encontrarnos con “cuellos de botella” en la red.

¿ Lentitud en IIS con FastCGI y PHP ?

Mediante FastCGI para IIS podemos tener soporte para PHP sobre el servidor de Microsoft para Windows (IIS).

No es la mejor opción para servir aplicaciones en PHP pero, cuando los requisitos de servidor son estos, no queda otro remedio.

Estos días he estado realmente ocupado en el desarrollo de de una plataforma de eCommerce sobre esta plataforma. Para mejorar el rendimiento se utiliza membase (algo más que un servidor de Memcache para windows), así como un sistema de datos híbrido: MySQL y MongoDB, Haanga como sistema de plantillas y como buscador una modificación del Zend_Search_Lucene.

Todo parecía ir bien hasta que empezamos a ver una extraña lentitud en algunas peticiones, por lo que, se revisaron las consultas, dando la más pesada (en el MySQL slow query log) 2 segundo, algo por debajo de los 20 segundos que tardaban algunas páginas, sin complejidad aparente.

No había una carga de red grande, ni un número de peticiones considerable simultáneas, pero había momentos de extrema lentitud.

No encontrando el origen, y comprobado que en el servidor de desarrollo y pre-producción, con los mismos datos, no se producían esos problemas, acabamos añadiendo, en producción, diferentes error_log() en zonas concretas para afinar el origen del problema.

Cada vez que se veían los logs, observábamos pautas muy diferentes, los tiempos eran aparentemente aleatorios, unas veces eran antes de una consulta sencilla, otras en el momento de renderizar la plantilla, otras a la hora de buscar un valor en la caché … aparecían en cualquier sitio y en cualquier momento, haciendo la web completamente inoperativa.

Una vez se descartaron los diferentes orígenes: MongoDB, Consultas SQL, Caché en memoria … me fijé en que los logs eran erráticos, no los veía como en un Unix con un tail -f, sino que los veía a saltos.

¿ Y si este era el problema ?

Efectivamente, mi suposición fue tan simple como: Con FastCGI se lanzan multiples procesos php5-cgi.exe que van recibiendo el código php y lo procesan, y si algo tiene Windows con los ficheros, especialmente NTFS, es una gran dificultad para poder añadir información al final de un fichero desde múltiples procesos. En este caso los simples error_log() que se lanzaban, provocaban bloqueos entre los distintos procesos FastCGI.

Sólo eliminando todos los error_log y grabaciones similares a archivos, y pasándolo a base de datos y todo volvió a la normalidad, velocidad correcta.

En resumen: Si no queda otra que utilizar un IIS con FastCGI + PHP, bajo ningún concepto utilizar ningún fichero para logs, o funciones como error_log() (que hacen lo mismo) ya que nos encontraremos con bloqueos de los diferentes procesos a la hora de acceder a ese archivo y añadir la información. En teoría grabar un log, básico, en Base de datos es menos eficiente que hacerlo en texto puro en un archivo, pero en Windows no tendremos más remedio que resolverlo así.

Nota: Desconozco si apache (mod_php) en windows tiene este problema.

He buscado en Internet alguna información sobre este problema, pero no he encontrado absolutamente nada.