Como aprovechar al máximo tu servidor

Este post comienza con la inquietud de migrar un blog que recibe hasta 100,000 visitas diarias, es decir que cuando se pública en esta red, genera hasta 1,000 requests por segundo, dependiendo la nota y el título, muchas de estas veces, se llegaba hasta 2,900 visitas simultáneas en tiempo real en Google Analytics usando WordPress y Mediatemple.

El punto es que al comenzar y hace un propio CMS para poder tener un control total de la comunidad sin atenernos a Buddypress, Cubepoints y otros plugins que lo que hacen es quitarte visitas saturando la base de datos.

Cual fue mi sorpresa al poner la app en producción, anunciarla y ver que se cayera y el load average subiera por los cielos con tan solo 50 visitas simultaneas:

Esto fue difícil de asimilar, porque un server de 1 GB en RAM de Amazon EC2 solo soporta 50 visitas.

Después de indagar, aprendí que esto se debe a que el sitio no debería estar generando vistas ni queries cada que tiene visitas, esto utiliza mucho CPU y RAM en. Por otro lado, estaba usando Apache2, y nginx tiene mejor performance según las gráficas.

apachevsnginx

Lo comprobé  haciendo el experimento nuevamente y podemos observar que logra soportar más de 100 usuarios simultáneos, definitivamente nginx funciona mejor que apache2 para optimizar recursos del server.

Ahora después de todo esto, el server se colgó de nuevo, ¿Pero que pasa?

Lo que pasa es que no se esta usando la tecnología de Cache correctamente, esto lo que hace, al primer visitante genera el query a la base de datos y el render de la vista, pero si cacheamos el query y la vista, a la segunda visita ya no va a hacer ningún query. Entonces observemos las vistas y veamos su performance:

laravelcache

Eso hace muchos queries, apesar de usar eager loading, eso sobrecalienta los servers de la base de datos y se cuelga debido a que ocupa 15.25MB en RAM del servidor cargar esto y distribuirlo porque renderea la vista y todos los querys.

Pero si esto lo cacheamos correctamente, podremos ahorrar quizá la mitad de recursos del servidor y poder repartir la carga con Amazon AWS ElastiCache.

Así que ya agregue un método en los controllers para poder cachear tanto los queries como la vista completa para reducir considerablemente el tiempo de carga:

priemracarga

Como podemos ver se redució considerablemente el tiempo de carga de 1,140 milisegundos a 211.25 milsegundos, es decir = 928.75 milisegundos menos.  Esto quiere decir que las siguientes cargas durante 60 minutos van a ser cacheada hasta que pasen estos 60 minutos la próxima carga del request que siga.

Para el código:

 public function viewPost($slug)
{
if(\Cache::has('post-'.$slug)) { //Se checa si no hay ya algo cacheado
$post = Cache::get('post-'. $slug); // Si si, entonces cargarlo y retornalo
return $post;
}
Cache::store('redis')->put('post-'.$slug, $this->cachePost($slug), 60); //Si no se encuentra entonces guardalo
$post = Cache::get('post-'. $slug);
return $post;
}

Y la funcion de cachePost()


<span style="line-height: 1.7;">public function cachePost($slug) </span><span style="line-height: 1.7;">{</span>

$post = \App\models\Post::where('slug', $slug)->with('user')->first();
if($post->type == 'video')
{
$info = Embed::create($post->featured_media);
$post->featured_media = $info->code;
$post->featured = $info->image;
$info->width = 650;
return \View::make('frontend.post', compact('post'))->render();
}
return \View::make('frontend.post', compact('post'))->render();
}

Y esta es otra vista que muestra videos, cargaba muy lento porque tenia muchos queries y vista, vean ahora como quedo:

otravista

Ahora viene la prueba final, hacer el commit y push para despues darle pull en el servidor y configurar .env las variables environment para usar Amazon AWS ElastiCache y redis y hagamos la prueba en la página que se nos caía cuando se hacían muchos requests:

ramsuccess

Podemos observar que de 542 milisegundos que tomó abrir la primera vez que no estaba cacheada, bajo a 83 milisegundos, y el ram disminuyó casi ¡20 megas en RAM!
Cachear es genial, pero ahora debo setear los tiempos para esto, que incremente, a menos que se edite o un comentario sea agregado.

Hagamos la prueba con tráfico para ver como se comporta y si puede tolerar más visitas de las de antes:

Como podemos observar ya soporta requests recurrentes ocupando menos CPU y menos RAM. Lo cual nos permite estabilizar el servidor y lograr economizar más en Elastic Beasntalk.

Anuncios

Accesar logs en tiempo real via terminal SSH

Estos comandos son realmente utiles para monitorear los logs(registros de lo que sucede en tu servidor) de los siguientes:

  • Apache access log: /usr/local/apache/logs/access_log
  • Apache error log: /usr/local/apache/logs/error_log
  • Domlogs: /usr/local/apache/domlogs
  • FTP/Server messages log: /var/log/messages
  • cPanel access log: /usr/local/cpanel/logs/access_log
  • cPanel error log: /usr/local/cpanel/logs/error_log

Estos se pueden accesar con el siguiente comando:

tail -f /usr/local/apache/logs/access_log

 

Ahi usen las carpetas de los diferentes logs y podran ver reportes en tiempo real de todos los que hacen GET , POST y mas REQUESTS.

Resolver problemas de exceso de espacio en /var/log en Ubuntu

He estado teniendo un gran problema con mi instancia de Linux Ubuntu 14.04. La carpeta de /var/log ocupaba 400 GB de mi disco duro de 500 GB. Me decidi adentrar para ver que estaba pasando y la solucion fue la siguiente:

  • sudo rm /var/log/*.1

Con esto libere 300 GB. Tambien borre todos los archivos .gz de esta misma carpeta y me libero 42 GB.

Al parecer ya quedo solucionado, tendre que adaptar un proceso que los limpie de vez en cuando.

Instalar Node.js y Phonegap en Linux Ubuntu

Estos son los pasos para instalar Phonegap y Node.js

  1. sudo apt-get install python-software-properties
  2. sudo apt-add-repository ppa:chris-lea/node.js
  3. sudo apt-get update
  4. sudo apt-get install nodejs
  5. sudo node -v
  6. sudo npm install -g phonegap

Usar PhoneGap:

$ phonegap create my-app
$ cd my-app
$ phonegap run android