Posts tagged ‘web server’

Scale out vs Scale up

There is no doubt that cloud hosting is taking its place and it offers some advantages for managing your deployments but, is it the right choice to take?

This dissertation comes from the recent new that StackOverflow uses a scale-up methodology to handle its services. And that’s a quite strange thing to see nowadays. Every single web service tends to use Scale-out and that’s the same for our company services, OpenHost, where we have been migrating from metal-servers to the cloud “panacea”.

Our main aim to move to cloud servers was to reduce our costs when our infrastructure is not having a lot of load, which always use to be at nights, and to quickly replace malfunctioning servers with new servers by provisioning them with puppet.

Just to clarify the terms, below I will describe both:

  • Scale-up: it is as simple as adding more computational power and RAM to your server, by buying a more expensive and robust server.
  • Scale-out: Refers to adding more servers with less processors and RAM.

There are common pros and cons for scale-up and scale-out which are:

  • Scale-up: they are less challenging to implement, and given that they can use all the power of the “metal” you will retrieve far better performance from the same machine in cloud. As a counterpart, using metal tends to be a risky business due to greater risk of hardware failure that causes bigger outages (yes we have learned this by heart).
  • Scale-out: as the opposite solution, using cloud based solutions tends to be easier to run fault-tolerance and easy to upgrade, but it will have a bigger footprint which raises some doubts about scale-up being harder to implement.

Scale out is usually cheaper overall and can literally scale theoretically infinitely (although we know that there are usually limits imposed by software or the environment’s infrastructure).

Our experience says that you will need more servers due to the fact that those VMs will have far less performance against metal-ones, but they have helped us to autoscale when our infrastructure had a huge demand. And we have mitigated a lot of outages caused by server failures.

A good resource to read is the Scalability Rules: 50 Principles for Scaling Web Sites which explains in a good way how to handle with this problem. But again, it’s quite weird nowadays that services like StackOverflow uses the scale-up technique, but they have probed that this have been worked better than scale-out for them.Take a look at how the StackOverflow was back in January 2014.

Web Server optimizado con Nginx (Nginx I)

Este post inicia una serie de post sobre Nginx, instalación, configuración y optimización todo fruto de el trasteo, la búsqueda de la máxima optimización, en parte impulsada por la limitación de recursos en general de el servidor en el que tengo alojada este humilde site.
En mi incursión en optimizar tanto el rendimiento como el consumo de memoria en mi servidor casero he estado probando Nginx. Despues de muchas pruebas y de escuchar en la red que era el mejor servidor.

Pero vayamos y echemos un ojo a todo de esta maravilla rusa. Nginx (“engine x”) es un servidor HTTP y proxy inverso de alto rendimiento, y un servidor proxy para IMAP/POP3/SMTP. Nginx fue desarrollado por Igor Sysoev para Rambler.ru, el segundo sitio web más visitado de Rusia, donde ha estado, y sigue, funcionando en producción más de dos años y medio. Igor ha lanzado el código fuente bajo una licencia estilo BSD. Nginx es conocido por su estabilidad, gran conjunto de características, configuración simple, y bajo consumo de recursos.
Nginx en estos momentos está haciendo mucho ruído precisamente porque para el caso de montar servidores web es muy rápido, sino el mejor, sirviendo estáticos, esto sumado a la posibilidad de configurar servidores proxy web inversos, nos permite tener un servidor con un rendimiento increíble y lo más importante y lo que más me impactó, en sólo 4 mben runtime.

Nginx es usualmente utilizado como reemplazo de apache que gestiona muchas conexiones concurrentes, como servidor proxy de balanceo de carga, como servidor proxy de mail, entre otros.

Dejemonos de alabanzas y procedamos a la instalación del mismo: En el momento que escribo tanto Debian Testing como Sid tienen unas versiones desfasadas  tiene nginx en su repositorio pero es una versión algo desfasada, 0.4.13, por lo que vamos a compilar e instalar la última versión:

Antes de nada instalaremos unas cuantas dependencias:

sudo aptitude install libpcre3 libpcre3-dev libpcrecpp0 libssl-dev zlib1g-dev

Hecho esto, ahora procedemos a recoger los fuentes, compilar y configurar.