Ver Mensaje Individual
  #6  
Antiguo 08-05-2013
Avatar de mamcx
mamcx mamcx is offline
Moderador
 
Registrado: sep 2004
Ubicación: Medellín - Colombia
Posts: 3.911
Reputación: 25
mamcx Tiene un aura espectacularmamcx Tiene un aura espectacularmamcx Tiene un aura espectacular
Cita:
Empezado por Ñuño Martínez Ver Mensaje
Un problema es que es un sistema en producción, así que pararlo es complicado.
Y quien ha dicho pararlo? Mas bien replicarlo. Copiar un backup y montarlo en otro servidor (ojala igualito). Se podria con cualquiera de los servicios en cloud y/o en una maquina virtual. El asunto es que si es un programa de terceros arreglarlo seria dificil/imposible dependendiendo si hay o no acceso al codigo fuente.

Cita:
Empezado por Ñuño Martínez Ver Mensaje
la aplicación no está preparada para soportar la carga (no lo sé seguro pero apuesto a que está totalmente hecha en PHP), y posiblemente el servidor tampoco.
Aun sin tocar el codigo, hay mucho que se puede hacer:

1- Usar un CDN como https://www.cloudflare.com/ para acelerar el proceso de descarga del front-end. La parte de servir html/js/css es normalmenten la mayor culpable del la lentitud percibida por el usuario final.

2- Cambiar a nginx (si usan apache)

3- Hacer lo que dice (tanto como se pueda): http://developer.yahoo.com/performance/rules.html

4- Montar un cache en frente de la app web, como https://www.varnish-cache.org/

5 - Luego viene el servidor en si. Digamos que no teniendo de otra probaria de inmediato con https://www.digitalocean.com/ si el problema es acceso al disco (por lo del SSD) o si el problema es memoria mas ram. Si tienen acceso fisico al servidor, comprar ram y listo. Es BARATO: http://www.amazon.com/Corsair-Vengea...words=ram+64gb (o 32GB, o 24GB)


Nada de lo anterior requiere tocar codigo, y permite comprar tiempo. Ademas, son cosas "faciles" de hacer. Con excepcion de mover la BD a otro servidor, no hay downtime de nada (y aunque haya que moverlo, no es necesario parar del todo, es posible hacer el cambio sin downtime)

Luego viene la BD en si. Con ajustes a los parametros se puede mejorar MUCHO. Ademas, si la BD comparte equipo con el servidor web, moverlo a un equipo dedicado es MEJOR.

Luego lo que viene es poner un "puente" entre la BD y el servidor web. Como no se que motor es, es cualquier cosa parecida a postgress como este: http://wiki.postgresql.org/wiki/PgBouncer.

AUN NO SE HA TOCADO CODIGO.

A partir de aqui, no se me ocurre que hacer sin tocar codigo. Que sigue?

1- Usar redis/memcached para cachear cosas (como html, consultas) <- Posiblemente el mayor salto en desempeño aparte de subir la RAM
2- Mejorar los SQL
3- Particionar datos, BD con balanceo de cargas, etc.
4- Por ultimo, si realmente estan creciendo como espuma, contratar gente que sepa del cuento y reescribir la app, de forma progresiva.
Mucho de esto se aprende con http://highscalability.com/
__________________
El malabarista.
Responder Con Cita