Varnish: Reduciendo carga de Nginx y Django en servidores

skamasle · 2013-08-27T08:58:06-0500

Hace un tiempo estuve alistando unos servidores con django para una web, sin duda que es el futuro y que si se tiene un proyecto grande es mucho mejor que PHP para algunos, a mi me gusta, y no tengo nada en contra de PHP, también lo uso bastante.

Pero bueno ese es otro tema, el tema aquí es que tanto puede ayudar varnish a nginx y según el instituto skamaslero de investigación y ocio en todos los servidores probados varnish reduce la carga, no imorta que combinación se use: ( lo digo por que algunos solo usan varnish en segundos servidores y otros solo bajo apache y no se atreben a combinar con nginx ( no se por que ))

Varnish -> nginx -> php
Varnish -> Nginx -> django
Varnish -> Lighttpd -> php
Varnish -> Nginx -> apache -> php (

7: )

En fin, para no marearlos unas capturas:

60 mil paquetes entrantes por segundo y -> 59 mbits.
34 mil paquetes salientes y -> 905 mbits

Mucho volumen de tráfico.

Nginx solo:

Entra varnish a ver que pasa:

Baja el consumo en general hasta un 54 % menos de consumo de mysql y notable caída en el consumo de nginx y como la carga en general bajo de entre 10 y 15 a 0.50 - 1

Pues eso, varnish salvando a nginx en los más duros momentos.

Aquí un tema nuevo con más detalles para mitigar ataques con nginx: Mitigar Ataques DDOS | Peticiones Get y Post | Skamasle

Wytzklaw · 2013-08-27T09:06:41-0500

Comentario: Que aún tengo bastante que aprender y que php no es la solución mágica con la que debo casarme.

Gracias por compartirlo :encouragement:

skamasle · 2013-08-27T09:43:32-0500

Santiago Maritz dijo:
Comentario: Que aún tengo bastante que aprender y que php no es la solución mágica con la que debo casarme.

Gracias por compartirlo :encouragement:

Pues si, php es muy usado, pero para webs con millones de visitas la solución es nodejs, django etc python es muy bueno, muy estable, rápido y muy seguro, php no esta mal y no tengo nada en contra, pero hay muchísimas soluciones, yo estoy pensando en migrar todos mis blogs wordpress a python, aunque es mero capricho, por que va bien wordpress ( php ) pero siempre es bueno probar.

shadowhck · 2013-08-27T09:55:20-0500

Por eso uso Varnish.

Varnish -> Apache -> PHP

Un claro ejemplo de sitios usando PHP, Facebook. :ghost:

Isidro · 2013-08-27T10:08:43-0500

Leí por encima porque tengo mucho sueño :distant:

skamasle dijo:
Hace un tiempo estuve alistando unos servidores con django para una web, sin duda que es el futuro y que si se tiene un proyecto grande es mucho mejor que PHP ( ¿que proyecto grande usa php? ) aunque bueno grande o pequeño django da siempre la talla.

shadowhck dijo:
Un claro ejemplo de sitios usando PHP, Facebook. :ghost:

Al parecer Facebook y su HipHop no es lo suficientemente grande.

skamasle · 2013-08-27T10:14:32-0500

shadowhck dijo:
Por eso uso Varnish.

Varnish -> Apache -> PHP

Un claro ejemplo de sitios usando PHP, Facebook. :ghost:

Facebook no usa solo PHP, además hicieron otro sistema, compilando PHP ( algo así nunca he leído a fondo del tema ) -> https://developers.facebook.com/blog/post/2010/02/02/hiphop-for-php--move-fast/ también dicen por ahí que han hecho su propio sistema de bds ( claro para almacenar tanta m+++ que se sube xD )

Pero vamos el tema no es usar PHP o otra cosa, se a desviado un poco eso jo jo.

El asunto es que si la web estuviera en PHP en vez de django tendría el mismo resultado con varnish, a eso iba enfocado el tema, varnish salvando a nginx, lo otro fue un comentario que me dio por hacer :sorrow::sorrow::sorrow::sorrow:

Para que no se molesten wikipedia usa php, 400 millones de visitas al mes

7: con nginx.

---------- Post agregado el 27-ago-2013 hora: 15:15 ----------

Isidro dijo:
Leí por encima porque tengo mucho sueño :distant:

Al parecer Facebook y su HipHop no es lo suficientemente grande.

A ver que el tema no es sobre PHP, es sobre varnish y nginx, además facebook no es 100% php :encouragement:

Eso pasa por leer por encima.

Isidro · 2013-08-27T10:19:58-0500

skamasle dijo:
A ver que el tema no es sobre PHP, es sobre varnish y nginx, además facebook no es 100% php :encouragement:

Eso pasa por leer por encima.

Lo que leí por encima no es lo que he respondido, eso vendrá luego si me acuerdo cuando me despierte de la siesta :moon: He opinado sobre la pregunta que está en negrita en mi cita. :topsy_turvy:

Facebook tiene una mezcla de lenguajes, pero por muy mezclado que esté sigue usando PHP.

skamasle · 2013-08-27T10:25:40-0500

Isidro dijo:
Lo que leí por encima no es lo que he respondido, eso vendrá luego si me acuerdo cuando me despierte de la siesta :moon: He opinado sobre la pregunta que está en negrita en mi cita. :topsy_turvy:

Facebook tiene una mezcla de lenguajes, pero por muy mezclado que esté sigue usando PHP.

Claro, usa PHP pero gracias a su hiphop si no quien sabe que sería de facebook si no lo hubieran desarrollado, aunque eso da igual, el tema es cuanto puede ayudar varnish :encouragement:.

Aunque bueno, tal vez me exprese mal en ese comentario, el asunto es que muchos grandes proyectos optan por django, node, ruby y otros sistemas, PHP no lo es todo, aunque malo tampoco es. ¿mejor así? :topsy_turvy::topsy_turvy:

shadowhck · 2013-08-27T11:04:20-0500

Una de las bondades de Varnish Cache, es que uno mismo puede montar una especie de Load Balancer. Y creo que al menos con contenido estatico funcionaria bien. En cuanto a la configuración, es bastante sencilla. :distant:

Datacenter1 · 2013-08-27T11:21:12-0500

Interesantes números, gracias por compartir

Te importaría ampliar un poco en detalles, me interesa conocer un poco más acerca de:
Hubo pérdida de paquetes durante el ataque?
Hardware utilizado?
alguna configuración especial en el sysctl.conf?

El tamaño promedio del paquete entrante parece ser 129 bytes

Absorber 60K pps con puro software no está nada mal ! y al juzgar por los números el límite real probablemente sea varias veces eso

Felicitaciones por esa buena configuración

skamasle · 2013-08-27T12:24:52-0500

Datacenter1 dijo:
Interesantes números, gracias por compartir

Te importaría ampliar un poco en detalles, me interesa conocer un poco más acerca de:
Hubo pérdida de paquetes durante el ataque?
Hardware utilizado?
alguna configuración especial en el sysctl.conf?

El tamaño promedio del paquete entrante parece ser 129 bytes

Absorber 60K pps con puro software no está nada mal ! y al juzgar por los números el límite real probablemente sea varias veces eso

Felicitaciones por esa buena configuración

Gracias

No es tanto como parece, o sea es puro software pero el merito se lo lleva la red del servidor que pudo aguantarlo, aunque fueron varios teras consumidos en tan solo 2 días :/, en otros servidores con 15 mil paquetes queda inaccesible el servidor, la otra ventaja es que la propia web tiene un consumo de RAM muy bajo y el resto fue cosa de varnish y memcached también andaba por ahí y aunque no parece nginx hizo un gran trabajo:

worker_rlimit_nofile 30000; :/

Por lo demás lo más relevante de hardware creo que fue el ssd por eso el nulo iowait y una ayuda extra para el ssd fue usar un poco de ram para algunos tmps y caches, con lo cual nos da:

Así el acceso es mucho mayor a los archivos también.

Aparte de eso el cache agresivo de varnish fue el salvador, el sistema casi no se modifico, glorioso debian.

Linux server 3.2
SSD Blaze
Xeon e3 1230
RAM:
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: Single-bit ECC
Maximum Capacity: 32 GB
Error Information Handle: Not Provided
Number Of Devices: 4

Handle 0x1100, DMI type 17, 28 bytes
Memory Device
Array Handle: 0x1000
Error Information Handle: Not Provided
Total Width: 72 bits
Data Width: 64 bits
Size: 4096 MB
Form Factor: DIMM
Set: 1
Locator: DIMM 2
Bank Locator: Not Specified
Type: DDR3
Type Detail: Synchronous
Speed: 1333 MHz

System Information
Manufacturer: HP
Product Name: ProLiant DL120 G7

OscarS · 2013-08-27T13:51:10-0500

Datacenter1 dijo:
Interesantes números, gracias por compartir

Te importaría ampliar un poco en detalles, me interesa conocer un poco más acerca de:
Hubo pérdida de paquetes durante el ataque?
Hardware utilizado?
alguna configuración especial en el sysctl.conf?

El tamaño promedio del paquete entrante parece ser 129 bytes

Absorber 60K pps con puro software no está nada mal ! y al juzgar por los números el límite real probablemente sea varias veces eso

Felicitaciones por esa buena configuración

Normalmente la mayoría de los "Remote DDoS Protection" usan casi la misma formula que el, que es tener un proxy con cache agresivo y agregar reglas para los flood get a eso sumale tener contrato un dedicado en una red con "protecion" como lo puede ser staminus donde se basa su granja de servidores.

skamasle dijo:
Gracias

No es tanto como parece, o sea es puro software pero el merito se lo lleva la red del servidor que pudo aguantarlo, aunque fueron varios teras consumidos en tan solo 2 días :/, en otros servidores con 15 mil paquetes queda inaccesible el servidor, la otra ventaja es que la propia web tiene un consumo de RAM muy bajo y el resto fue cosa de varnish y memcached también andaba por ahí y aunque no parece nginx hizo un gran trabajo:

worker_rlimit_nofile 30000; :/

Por lo demás lo más relevante de hardware creo que fue el ssd por eso el nulo iowait y una ayuda extra para el ssd fue usar un poco de ram para algunos tmps y caches, con lo cual nos da:

Así el acceso es mucho mayor a los archivos también.

Aparte de eso el cache agresivo de varnish fue el salvador, el sistema casi no se modifico, glorioso debian.

Linux server 3.2
SSD Blaze
Xeon e3 1230
RAM:
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: Single-bit ECC
Maximum Capacity: 32 GB
Error Information Handle: Not Provided
Number Of Devices: 4

Handle 0x1100, DMI type 17, 28 bytes
Memory Device
Array Handle: 0x1000
Error Information Handle: Not Provided
Total Width: 72 bits
Data Width: 64 bits
Size: 4096 MB
Form Factor: DIMM
Set: 1
Locator: DIMM 2
Bank Locator: Not Specified
Type: DDR3
Type Detail: Synchronous
Speed: 1333 MHz

System Information
Manufacturer: HP
Product Name: ProLiant DL120 G7

Por mi parte, a mi no me gusta usar varnish por el hecho que no se nota una diferencia al usarlo con nginx lo he probado varias veces y como dices puede que haga el gasto de menos recursos, pero al navegar no hay un cambio drástico notable en el sitio por lo que usarlo con nginx no es de mucho uso como la mayoría de la gente piensa (y eso que busque mucha información para saber el perfomance) aunque para DDoS todo mundo sabe que sirven los proxys como mencione arriba no es mala la información que pusiste. En mi caso prefiero usar varnish para sistemas con apache y solamente cuando es necesario con nginx ya que con apache el cambio es notablemente.

Saludos.

skamasle · 2013-08-27T14:00:02-0500

OscarS dijo:
Normalmente la mayoría de los "Remote DDoS Protection" usan casi la misma formula que el, que es tener un proxy con cache agresivo y agregar reglas para los flood get a eso sumale tener contrato un dedicado en una red con "protecion" como lo puede ser staminus donde se basa su granja de servidores.

Por mi parte, a mi no me gusta usar varnish por el hecho que no se nota una diferencia al usarlo con nginx lo he probado varias veces y como dices puede que haga el gasto de menos recursos, pero al navegar no hay un cambio drástico notable en el sitio por lo que usarlo con nginx no es de mucho uso como la mayoría de la gente piensa (y eso que busque mucha información para saber el perfomance) aunque para DDoS todo mundo sabe que sirven los proxys como mencione arriba no es mala la información que pusiste. En mi caso prefiero usar varnish para sistemas con apache y solamente cuando es necesario con nginx ya que con apache el cambio es notablemente.

Saludos.

Depende del sistema no vas a ver diferencia con varnish, varnish es que cachea, ese es el truco si tienes nginx con ssd no verás mucha diferencia al menos que sea un número considerable de peticiones y que quieras cachear algo más que imágenes y para varnish hay muchas configuraciones, solo es buscar la mejor, tanto así que me han pedido a veces varnish -> nginx -> apache.

Por lo demás lo del proxy, pues en este caso no hubo proxy externo ni nada por el estilo, solo se trabajo en un servidor que es el que recibía el ataque, el data center no ayudo en nada y fue una suerte que no venia nada por udp por que por poco que manden te hacen null route ahí y mínimo 6 horas off.

gomhermar · 2013-08-27T14:01:03-0500

Muy interesante estos datos, querría ver como se comportaría esto haciendo funcionar varnish en un servidor para el solo y el resto en otro.

pero muy interesantes los números.

un saludo

OscarS · 2013-08-27T14:08:39-0500

skamasle dijo:
Depende del sistema no vas a ver diferencia con varnish, varnish es que cachea, ese es el truco si tienes nginx con ssd no verás mucha diferencia al menos que sea un número considerable de peticiones y que quieras cachear algo más que imágenes y para varnish hay muchas configuraciones, solo es buscar la mejor, tanto así que me han pedido a veces varnish -> nginx -> apache.

Por lo demás lo del proxy, pues en este caso no hubo proxy externo ni nada por el estilo, solo se trabajo en un servidor que es el que recibía el ataque, el data center no ayudo en nada y fue una suerte que no venia nada por udp por que por poco que manden te hacen null route ahí y mínimo 6 horas off.

Yo tengo ya unos meses donde para un solo sitio de igual forma configure nginx (si con debian, aunque ahora estoy mas con centos) sin varnish y soportaba 50-90k de peticiones por segundo claro que tenia un uso del 30% de CPU y le hice una configuración a medida de su trafico y servidor, aunque soportaba mas trafico y la maquina era de las mejores del mercado (no cluster) así que realmente varnish con nginx lo veo solo para usos especiales, no digo que sea malo pero nginx no le pide nada a varnish aunque es un buen complemento.

De todas formas es interesante leer esto.

Saludos.

skamasle · 2013-08-27T14:09:23-0500

gomhermar dijo:
Muy interesante estos datos, querría ver como se comportaría esto haciendo funcionar varnish en un servidor para el solo y el resto en otro.

pero muy interesantes los números.

un saludo

Ya lo he hecho funcionar así en algunos ataques de menor escala en servidores más pequeños, varnish en uno y el resto en 2 vps, lo mismo que nginx de balanceador con proxy cache, me convence más nginx de proxy y varnish en los 2 vps con la web.

He hecho muchas pruebas y hay realmente buenas combinaciones :encouragement:

r2j · 2013-08-27T14:11:57-0500

Muy buen post! :encouragement:

skamasle · 2013-08-27T14:15:10-0500

OscarS dijo:
Yo tengo ya unos meses donde para un solo sitio de igual forma configure nginx (si con debian, aunque ahora estoy mas con centos) sin varnish y soportaba 50-90k de peticiones por segundo claro que tenia un uso del 30% de CPU y le hice una configuración a medida de su trafico y servidor, aunque soportaba mas trafico y la maquina era de las mejores del mercado (no cluster) así que realmente varnish con nginx lo veo solo para usos especiales, no digo que sea malo pero nginx no le pide nada a varnish aunque es un buen complemento.

De todas formas es interesante leer esto.

Saludos.

Notarás diferencia con varnish si usas por ejemplo wordpress y un plugin de cache, el cache es en html, le dices a varnish que cachee el html y ahí verás que mejora, todo se sirve desde la ram, si es php se puede hacer si es muy agresivo el cache pero luego vienen las quejas de que la web no se actualiza cuando algo nuevo se publica, pero si pones varnish para js, css e imágenes no hay mucha diferencia, al menos que, el servidor tenga un disco sata y las peticiones sean tantas que nginx genere mucho IO WAIT, ahí si le deja por el suelo varnish, también hay que ver cuanta ram se le da a varnish para que cachee, ese es el pequeño secreto, nginx es muy bueno sirviendo estático y varnish también es bueno para algunas cosas.

OscarS · 2013-08-27T14:21:05-0500

skamasle dijo:
Notarás diferencia con varnish si usas por ejemplo wordpress y un plugin de cache, el cache es en html, le dices a varnish que cachee el html y ahí verás que mejora, todo se sirve desde la ram, si es php se puede hacer si es muy agresivo el cache pero luego vienen las quejas de que la web no se actualiza cuando algo nuevo se publica, pero si pones varnish para js, css e imágenes no hay mucha diferencia, al menos que, el servidor tenga un disco sata y las peticiones sean tantas que nginx genere mucho IO WAIT, ahí si le deja por el suelo varnish, también hay que ver cuanta ram se le da a varnish para que cachee, ese es el pequeño secreto, nginx es muy bueno sirviendo estático y varnish también es bueno para algunas cosas.

Como dije, el uso de varnish lo veo necesario solo en algunos casos de igual forma tu cliente era django mientras que el mio típico php/mysql y aun así tenia 15k~ de online. Como sea el uso de varnish no digo que este mal con nginx pero la verdad yo (en mi caso personal) solo lo uso cuando lo veo necesario otra cosa es que tu recibías trafico malicioso mientras que yo no y ambos sistemas son conocidos por poder combatir DDoS sin problema (aunque como dices para UDP tendras que contratar algo con proteccion).

Un gran saludo.

shadowhck · 2013-08-27T14:23:43-0500

skamasle dijo:
Notarás diferencia con varnish si usas por ejemplo wordpress y un plugin de cache, el cache es en html, le dices a varnish que cachee el html y ahí verás que mejora, todo se sirve desde la ram, si es php se puede hacer si es muy agresivo el cache pero luego vienen las quejas de que la web no se actualiza cuando algo nuevo se publica, pero si pones varnish para js, css e imágenes no hay mucha diferencia, al menos que, el servidor tenga un disco sata y las peticiones sean tantas que nginx genere mucho IO WAIT, ahí si le deja por el suelo varnish, también hay que ver cuanta ram se le da a varnish para que cachee, ese es el pequeño secreto, nginx es muy bueno sirviendo estático y varnish también es bueno para algunas cosas.

Todo es cuestion de adaptar el VCL de Varnish. En mi caso uso Varnish con cache en disco, y se cachea el contenido dinamico (Respetando usuarios logueados, y las cookies de WP) y el estatico. El VCL personalizado que uso consta de 500 lineas, que me tomo semanas pulir para que funcionara en WordPress sin ningun problema; solo instale un plugin de purga en WP, y todo funciona como deberia de funcionar. Y como la purga es automatica, tengo la expiracion del contenido dinamico y adjuntos de la web (jpg, css, js) en 7 dias, el robots.txt y el sitemap.xml en 5 minutos, etc.

Y aunque la cache sea en disco, la velocidad comparado con solo Apache es notable.