No lo entiendo
Ayer domingo por la mañana actualicé el Apache, PHP y MySQL de eso. Debido a que el tráfico era bastante inferior a lo normal –por el puente– decidí habilitar la compresión gzip en el PHP y también en el Apache (con el mod_deflate). Pensé que el consumo de CPU se dispararía hoy lunes con el aumento de tráfico, de hecho lo llevo controlando casi todo el día.
Pero es que no sólo no ha subido, también está por debajo de los niveles de cargas habituales a pesar de estar en “horas pico” (unas 5000 visitas/hora, diría que la carga ha bajado un 20-30% por lo menos):
$ uptime 17:45:41 up 45 days, 17:12, 4 users, load average: 0.48, 0.54, 0.53 $ uptime 17:54:53 up 45 days, 17:21, 4 users, load average: 0.45, 0.45, 0.48
Podría pensar que la mejora del Apache 2.2 en la gestión de las conexiones persistentes tuviese algo que ver. O que el rendimiento del PHP 5.2 es muy superior al del 5.1 (aunque he leído estudios que demuestran que no lo es).. ¿pero tanta diferencia? ¿influirá también en que se “descarga” de la gestión de las conexiones TCP/IP al haber muchos menos datos que transmitir? (un 20-25% del total sin comprimir) ¿mejor aprovechamiento del hyperthreading de los procesadores Xeon?.
No lo entiendo. ¿Alguna idea?
PS: Tampoco entiendo porqué muchos IE (sobre todo el 6) se bajan el CSS cada vez y porqué no aceptan la versión comprimida… pero me agobiaré con esto más adelante.
Yo me inclinaría por la “descarga” de la gestión de conexiones, ya que, debido a que tiene menos que transmitir, termina antes, por lo que se libera antes.
Seguramente si llegará a cargar la CPU, pero mínimamente, al ser archivos pequeños, pero el % de carga de CPU es muchísimo menor, comparado el % de compresión de los datos que, en el caso de ficheros de texto (no tiene sentido con las imagenes que ya están comprimidas) es muy grande.
Total, mucho menos que enviar por muy poco proceso, y se liberan antes los recursos asociados a las peticiones. Esto es lo que intuyo…
Comment by Luismi — Monday 11/12/2006 @ 18:52
Respuesta rápida: Vudú
Respuesta lenta: Me inclino porque la carga de la gestión de las conexiones de la red, la controle la CPU del servidor (lo cual no es ni mucho menos lógico). Al habilitar la compresión gzip, disminuye la cantidad de datos a transmitir = a gestionar por la CPU, con lo cual la carga del servidor se reduce. Me inclino porque sea esto, aunque demostraría que las tarjetas de red que usan no son digamos……de muy alta gama.
Respuesta chorra: Alguien ha rezado mucho ultimamente…..
Comment by Jero — Monday 11/12/2006 @ 20:52
Por mi propia experiencia, reducir el número de conexiones por procesos de apache que tiene que mantener la cpu, produce un gran alivio de carga en la cpu. Pero nunca habia pensado que aplicando compresión para la transmisión fuese tan efectivo (me hubiera inclinado por un aumento). Por supuesto, no siempre se puede aplicar ese método :-(, pero es un camino interesante.
Un saludo.
Comment by alidhaey — Monday 11/12/2006 @ 21:22
Menos numero de conexiones, menos procesos para el Apache que cargan la CPU, y de paso, utiliza los juegos de instrucciones que los procesadores modernos llevan incluidos para reducir la carga. Fácil cómodo y sencillo. Implementado por defecto en otros servidores menos conocidos. Hace algún tiempo.
Comment by Peanut — Monday 11/12/2006 @ 21:37
Como ya dicen por ahí, a más compresión menos datos que transmitir, menos gasto de CPU en la parte de software que manda los datos al usuario (pila TCP/IP, copiado de datos de espacio de usuario al kernel). Hay que tener en cuenta que la carga del sistema, si no me equivoco, se calcula a partir de los procesos que estan “esperando” a ejecutarse. No es el “tiempo gastado de CPU por los procesos”, que es lo que tú pareces esperar ver incrementarse (y probablemente así haya sido)
Comment by Diego — Tuesday 12/12/2006 @ 0:51
La carga mide la media de procesos en la cola de listos de para ejecutar. Si los procesos apache/php tienen que hacer trabajo adicional consumen más CPU y la media se tiene que elevar.
Quizás estén quitando algo de “trabajo” a la pila TCP/IP, pero no puede ser tanto que compense la compresión on-the-fly de tantas páginas y además bajo el consumo de CPU…. no sé, quizás tenga que ver con el HT o que usa instrucciones adicionales del procesador que antes no se usaban y por lo tanto no hay un “mayor consumo”…
O que en realidad la compresión que hace (ahora está a nivel 1) consume muy poca CPU.
Comment by gallir — Tuesday 12/12/2006 @ 1:02
“La carga mide la media de procesos en la cola de listos de para ejecutar. Si los procesos apache/php tienen que hacer trabajo adicional consumen más CPU y la media se tiene que elevar.”
A eso me refiero, si esta descomprimido se tarda menos en enviar los datos y por lo tanto con un determinado número x de conexiones simultaneas por segundo debería haber menos procesos presentes de manera simultanea. Es decir, el retardo que pueda producir el comprimir la página probablemente sería mucho menor que el retardo producido por tener que mandar los datos 5x más grandes de los normales…aunque por otra parte es cierto que cuesta creer que el gzip cueste tan poco.
De cualquier modo, es curioso que el enigma que discutimos sea “¿por qué consume tan poco este servidor?” y no “por qué consume tanto”. Ventajas del software libre
Comment by Diego — Tuesday 12/12/2006 @ 1:15
Medio-offtopic: Pues oye, ya sólo falta que habilites Gzip en WP-Cache y ponerse a hacer pruebas antes y después para ver si es algo solamente de Apache o no…
Comment by Armonth — Tuesday 12/12/2006 @ 3:24
El IE tiene problemas a la hora de “procesar” CSS y JS comprimido. ¿Es posible que en la configuración del Apache estos ficheros no se estén comprimiendo, dado que este problema es conocido?
Saludos
Comment by álvaro — Tuesday 12/12/2006 @ 9:34
Hola, Ese problema que comentas con el IE, creo que es porque son usuarios detrás de un proxy (concretamente un ISA Server). Este proxy suele borrar las cabeceras del navegador, y siempre solicita que se envíen los datos sin comprimir.
Comment by DN — Tuesday 12/12/2006 @ 10:20