Llevo con mi proyecto más de dos años pero fué en los últimos meses en que comenzó a crecer de forma desproporcionada y comenzó a escapar de mi contról.
Que sucedió
Básicamente, jugué bién algunos movimientos estratégicos que mejoraron las visitas de mi aplicación que se embebe en otros sitios web, como el botón de "me gusta" de facebook, por ejemplo.
Esta "buena jugada" generó que en menos de una semana pase de 100 visitas por día a 25 mil, en 2 semanas 35 mil, en 3 semanas 50 mil y así sucesivamente hasta que a día de hoy genero más de 130 mil por día de estas "aplicaciones embebidas".
El problema
Claramente, este tipo de cosas no sucede todos los días y no siempre uno piensa en "escalar". Por ello me ví en varios problemas, primero y principal fué que mi hosting compartido me botó. Algo que me dió la pauta de implementar servidores de respaldo.
Esto funciona de la siguiente manera: tu sitio web que tiene la aplicación instalada envia una petición al servidor principal y si este servidor responde envia una petición allí, caso contrario escoje de forma random uno de los 3 servidores de respaldo.
Luego de pasarme a un VPS, me ví en un serio problema de costos, escalé el VPS de manera muy rápida. Más precisamente, en menos de 3 semanas escalé al Level 9 de Hostgator, dicho nivel, supuestamente entrega más de 5Ghz de procesamiento, algo que tampoco me alcanzaba.
La solución (o eso creia)
Creí que Hostgator me mentía y multiplicaba mi consumo por ende decidí mover a una solución cloud, pensando siempre a futuro, claro está.
Moví todo a la solución cloud, invertí en la puesta a punto, tiempo, esfuerzo y dinero y me topé con la sopresa que mi consumo de procesador se redujo en un 50%, esto puede ser por dos cosas:
- El procesador de la plataforma Cloud es más potente que el de Hostgator
- Hostgator me estuvo mintiendo todo este tiempo
De todos modos, no se si no lo quize ver o que, el problema seguía. Cuando activaba el servidor principal y toda la carga recaía sobre él, dicho servidor se iba a 400% de procesador.
El verdade problema
El 85% de mi consumo estaba en las consultas MySQL. Era taaaaan pero taaan simple que solo me compadece el hecho de que cuando comencé con el proyecto no era tan "vivo" con la escalabilidad ni pensé que sucedería algo así.
El problema fué que utilizaba en las búsquedas un identificativo generado por HASH, recortado mas un salt. Esto hacia que cada día al agregarse más de 4 millones de filas, la búsqueda cada día dure más y más.
Ejecutando la consulta, ví que llegaba a durar de 1 segundo a 0.8, 0.5 segundos, si lo multiplico por 5 o 6 consultas, dá el tiempo de carga que tenía actualmente.
La verdadera solución
La solución final fué pasar las búsquedas a columnas autoincrementales, las cuales las tenía pero no sé si por pereza o que no las utilizaba. En realidad las usaba para cuando quería ordenar las filas en phpmyadmin y ver la última generada (bueno, también podia usar la fecha, ahora que lo pienzo).
Una buena práctica que siempre utilizé fué crear un autoincrement en TODAS las tablas, algo que hago automáticamente, pero que generalmente no utilizo, en cambio, utilizo un UUID alfanumerico. Y esto, fué lo que me ahorró más de 350% de consumo, el pasar las consultas a Autoincrement.
Otras cosas también bajaron aún más mi consumo, como por ejemplo, no utilizar SELECT COUNT(*) sinó SELECT COUNT(columnaautoincrement), por ejemplo. Pero, principalmente, fué lo primero.
La lección
SIEMPRE utilizar autoincrement de forma activa. Ya sea para seleccionar en un WHERE, para UPDATE o lo que sea. Siempre!
