<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">El lun., 26 sept. 2016 a las 11:27, Antonio Beamud Montero (<<a href="mailto:antonio.beamud@gmail.com">antonio.beamud@gmail.com</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">El 25/09/16 a las 13:51, Chema Cortes escribió:<br>
> Se puede dar un buen servicio con apache, pero conseguir que sea<br>
> escalable es complicado. Mientras, nginx se adapta muy bien a los<br>
> incrementos de demandas, sobre todo si se trata de enviar streams de<br>
> datos.<br>
Hola Chema, ¿en que casos crees que apache no escala bien? Hasta ahora,<br>
los casos que me he encontrado yo, no eran problema de apache, sin el<br>
backend detrás de él.<br></blockquote><div><br></div><div>Creo que @lasizoillo ha contestado a la pregunta.<br><br></div><div>La respuesta corta es que apache va bien para ejecuciones cortas, mientras que nginx es más adecuado para ejecuciones largas.<br></div><br></div><div class="gmail_quote">Yo especificafa el caso de envío de streams, que puede ser para enviar vídeo, pero que también puede verse como el típico chat o red social tipo twitter o de visualización de cotizaciones de bolsa. Puedes superdimensionar un sistema de nodos apache para que tenga workers suficientes que den respuesta a todas las conexiones que reciba. Por supuesto, por culpa de la programación de los backends, estos workers degeneran y empiezan a sufrir bloqueos y a quedarse sin memoria. Se configuran para que los workers se "autosuiciden" al cabo de un número de conexiones (MaxConnectionsPerChild) y liberen los recursos que quedaban bloqueados. Pero ¿qué pasa cuando dedicas una conexión a un stream que requiere de una conexión más larga? ¿o como dice lasiozillo, si estas sufriendo una situación similar a un ataque slowloris porque las conexiones de tu cliente son excesivamente lentas? El worker degenera sin remedio, lo que va dejando pocos workers disponibles en el pool para nuevas conexiones, lo que reduce la capacidad de respuesta del servidor. Hay muy pocos que programen conscientemente de los problemas que tendrán sus programas en ejecuciones largas.<br><br></div><div class="gmail_quote">Con un servidor asíncrono, como nginx, puedes dedicar una conexión a cada cliente y crear "continuaciones" (corrutinas) que son bastante livianas y cuyo proceso se ajusta a la capacidad de proceso que tenga tu máquina, asegurando su escalabilidad. Se puede decir que nginx puede responder a cualquier número de peticiones concurrentes que se le haga, aunque sea muy lentamente. Basta aumentar el número de nodos para mejorar la respuesta. Al igual que apache, también una mala programación puede tumbar el servidor nginx. Pero si realizas una buena programación asíncrona, que evite bloqueos y use operaciones atómicas (CAS), se consigue una ejecución bastante pacífica de un gran número de procesos simultáneos.<br><br></div></div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr"><span>Hyperreals *R  "Quarks, bits y otras criaturas infinitesimales": </span><a href="http://ch3m4.org/blog">http://blog.ch3m4.org</a><br></div></div>