Bueno, pues después de muchas vueltas, hemos decidido volver a retomar Apache en detrimento de Nginx.
La decisión está basada en el sistema de actualización, y en que vamos a desplegar una red nueva, con distintos servidores, y separando servicios que es lo que interesa.
Supongo que iré escribiendo algo de las optimizaciones. De todos modos tengo que probar a ver que tal funciona la kurobox con un nginx y con pylons en casita, aunque de noche la tenga que apagar por el ruido :-)
26 marzo 2008
Vuelta a Apache
Publicado por
jmcalvar
en
6:15 p. m.
0
comentarios
Enviar por correo electrónicoEscribe un blogCompartir en XCompartir con FacebookCompartir en Pinterest
Etiquetas:
apache,
servidores web
14 marzo 2008
Nginx y el querystring
Hasta ayer he estado utilizando sin (aparentemente) ningún problema Nginx como frontend de un servidor web.
Ayer nos dimos cuenta de que las cosas no estaban pitando demasiado bien en una petición (un poco rara, la verdad) que un programa hace a ese servidor.
Comprobamos que con apache funcionaba, pero que con nginx no, lo cual me llevó ha hacer una regla de reescritura, pero la URL final que quedaba (y que hacía que funcionara) no nos convencía demasiado.
Finalmente encontramos el problema.
Si tenemos una URL como ésta: http://www.dominio.com?loquesea
Apache la transforma en: http://www.dominio.com/?loquesea
Y nginx la transforma en: http://www.dominio.com
Es decir, nginx se carga la parte que va detrás del interrogante, con lo cual "nos desmonta el negocio".
A mi pesar, y hasta que encuentre solución he tenido que volver a levantar apache como frontend, y ahora estoy haciendo maravillas sirviendo imágenes desde otro servidor (con nginx por supuesto), activando el mod_expire de apache para los ficheros html (Este servidor soporta alrededor de un millón de visitas diarias).
Seguimos a la caza del query_string perdido ....
Ayer nos dimos cuenta de que las cosas no estaban pitando demasiado bien en una petición (un poco rara, la verdad) que un programa hace a ese servidor.
Comprobamos que con apache funcionaba, pero que con nginx no, lo cual me llevó ha hacer una regla de reescritura, pero la URL final que quedaba (y que hacía que funcionara) no nos convencía demasiado.
Finalmente encontramos el problema.
Si tenemos una URL como ésta: http://www.dominio.com?loquesea
Apache la transforma en: http://www.dominio.com/?loquesea
Y nginx la transforma en: http://www.dominio.com
Es decir, nginx se carga la parte que va detrás del interrogante, con lo cual "nos desmonta el negocio".
A mi pesar, y hasta que encuentre solución he tenido que volver a levantar apache como frontend, y ahora estoy haciendo maravillas sirviendo imágenes desde otro servidor (con nginx por supuesto), activando el mod_expire de apache para los ficheros html (Este servidor soporta alrededor de un millón de visitas diarias).
Seguimos a la caza del query_string perdido ....
Publicado por
jmcalvar
en
10:40 a. m.
0
comentarios
Enviar por correo electrónicoEscribe un blogCompartir en XCompartir con FacebookCompartir en Pinterest
Etiquetas:
apache,
nginx,
servidor web
11 marzo 2008
Balanceadores de Carga en Linux
He estado haciendo pruebas con diferentes balanceadores de carga (load balancers), para ver si de esa manera podemos mejorar el servicio de descarga de programas.
Como las máquinas están en producción, he descartado el lvs, pese a que lo tengo en otras máquinas con satisfactorios resultados. Además las máquinas son muy heterogéneas con lo cual no estoy por la labor de estar cambiándoles los nombres para realizar algunas pruebas y luego deshacer todo.
Los balanceadores con los que he hecho las pruebas han sido balanceadores software, y sobre linux por supuesto.
No he hecho todavía pruebas de rendimiento, sino de funcionalidad, facilidad, modularidad, características, etc...
Los que he probado hasta el momento han sido:
Por supuesto otro punto negativo es la ip que veo en los logs de los servidores web, puesto que al actuar como proxy inverso insertan la ip del balanceador. Claro está que con pequeñas modificaciones en los logs se puede recuperar, pero ya supone más procesamiento de logs.
En resumen, no me convencen demasiado, pero hay que probar, de hecho el autor de Crossroads indica que sus benchmarks eran muy similares a las de lvs.
Como las máquinas están en producción, he descartado el lvs, pese a que lo tengo en otras máquinas con satisfactorios resultados. Además las máquinas son muy heterogéneas con lo cual no estoy por la labor de estar cambiándoles los nombres para realizar algunas pruebas y luego deshacer todo.
Los balanceadores con los que he hecho las pruebas han sido balanceadores software, y sobre linux por supuesto.
No he hecho todavía pruebas de rendimiento, sino de funcionalidad, facilidad, modularidad, características, etc...
Los que he probado hasta el momento han sido:
- Pound
- Crossroads
- Nginx (como balanceador)
- Balance
Por supuesto otro punto negativo es la ip que veo en los logs de los servidores web, puesto que al actuar como proxy inverso insertan la ip del balanceador. Claro está que con pequeñas modificaciones en los logs se puede recuperar, pero ya supone más procesamiento de logs.
En resumen, no me convencen demasiado, pero hay que probar, de hecho el autor de Crossroads indica que sus benchmarks eran muy similares a las de lvs.
Publicado por
jmcalvar
en
5:53 p. m.
0
comentarios
Enviar por correo electrónicoEscribe un blogCompartir en XCompartir con FacebookCompartir en Pinterest
Etiquetas:
balanceadores de carga,
load balancers,
servidor web
05 marzo 2008
Descargas de servidores web
Llevo casi mes y medio lidiando con las descargas que tenemos en un servidor web. A raíz de un problema que tuvimos conseguimos detectar varios problemillas secundarios, que parece que ya están arreglados.
Desde hace un tiempo estamos luchando por conseguir detectar por qué han descendido los porcentajes de descargas respecto a las visitas.
Primeramente hay que hacer notar que el porcentaje de visitas lo tomamos de Google analytics, y el de descargas del log del servidor. En el servidor de descargas tenemos nginx.
Hemos probado varias cosas, balancear las descargas entre servidores heterogéneos, nginx, lighttpd, apache; jugar con los keepalive.
He estado dándole vueltas a configurar varnish como proxy cache, pero después de darle vueltas a la idea, me he dado cuenta de que el problema no es el "throughput" sino la descarga propiamente.
Supongo que todo viene del cambio de instalador. Previamente teníamos un instalador web, se descargaba un fichero pequeñito y este se encargaba de descargar los ficheros que necesitara. Ahora tenemos un fichero grande con todos los ficheros, de modo que la instalación es más grande, pero sospecho que a muchos usuarios no les gusta esta solución y cancelan la descarga al ver que descargan un fichero de 12 Mb.
Sigo investigando. Se aceptan ideas :-)
Desde hace un tiempo estamos luchando por conseguir detectar por qué han descendido los porcentajes de descargas respecto a las visitas.
Primeramente hay que hacer notar que el porcentaje de visitas lo tomamos de Google analytics, y el de descargas del log del servidor. En el servidor de descargas tenemos nginx.
Hemos probado varias cosas, balancear las descargas entre servidores heterogéneos, nginx, lighttpd, apache; jugar con los keepalive.
He estado dándole vueltas a configurar varnish como proxy cache, pero después de darle vueltas a la idea, me he dado cuenta de que el problema no es el "throughput" sino la descarga propiamente.
Supongo que todo viene del cambio de instalador. Previamente teníamos un instalador web, se descargaba un fichero pequeñito y este se encargaba de descargar los ficheros que necesitara. Ahora tenemos un fichero grande con todos los ficheros, de modo que la instalación es más grande, pero sospecho que a muchos usuarios no les gusta esta solución y cancelan la descarga al ver que descargan un fichero de 12 Mb.
Sigo investigando. Se aceptan ideas :-)
Publicado por
jmcalvar
en
12:16 p. m.
0
comentarios
Enviar por correo electrónicoEscribe un blogCompartir en XCompartir con FacebookCompartir en Pinterest
Etiquetas:
servidor web
21 febrero 2008
Insecure Magazine 15
Con cierto retraso escribo esta reseña a Insecure Magazine, pero estoy de trabajo hasta arriba.
Ahora que estoy liado con los anchos de banda, tiempos de descarga, etc, etc., el artículo que estoy devorando por momentos es el de herramientas de monitorización.
En fin, aquí están los contenidos y el enlace a la descarga (todo en inglés):
Ahora que estoy liado con los anchos de banda, tiempos de descarga, etc, etc., el artículo que estoy devorando por momentos es el de herramientas de monitorización.
En fin, aquí están los contenidos y el enlace a la descarga (todo en inglés):
- Proactive analysis of malware genes holds the key to network security
- Advanced social engineering and human exploitation
- Free visualization tools for security analysis and network monitoring
- Internet terrorist: does such a thing really exist?
- Weaknesses and protection of your wireless network
- Fraud mitigation and biometrics following Sarbanes-Oxley
- Application security matters: deploying enterprise software securely
- The insider threat: hype vs. reality
- How B2B gateways affect corporate information security
- Reputation attacks, a little known Internet threat
- Data protection and identity management
- The good, the bad and the ugly of protecting data in a retail environment
- Malware experts speak: F-Secure, Sophos, Trend Micro
- AND MORE!
Publicado por
jmcalvar
en
4:11 p. m.
0
comentarios
Enviar por correo electrónicoEscribe un blogCompartir en XCompartir con FacebookCompartir en Pinterest
Etiquetas:
insecure magazine,
seguridad magazine
Suscribirse a:
Entradas (Atom)