Barrapunto

Si vas a montar un servidor web, una parte critica en el rendimiento son las aplicaciones que van a estar funcionando. No conozco mucho Mambo, pero parece bastante pesado.

Uno de los factores que mas carga consumen, es el numero de consultas que hace la aplicacion (en este caso Mambo) a la base de datos. Si puedes configurar la aplicacion para reducir esto, te aseguro que notaras mucho la diferencia de rendimiento. Mira a ver que modulos carga Mambo, si puedes no cargar alguno para que vaya mas ligero, ese tipo de cosas.

Por otro lado, no se si Mambo tiene cache, lo cual reduce mucho el numero de consultas a la base de datos.

Te recomiendo como gestor de Contendidos spip, (http://www.spip.net/es ) tiene un sistema de cache muy muy bueno, puede seguir funcionando aunque el servidor de base de datos este caido, (aunque no te deja cambiar contenidos, claro) y consume muy muy pocos recursos.

Buenas, te voy a dar unas pocas reglas, que creo que son suficientes para que tu aplicación vaya rápido.
1.- Haz estático todo lo que pueda ser estático.
2.- Si no puedes hacer estático lo que debe ser estático, usa caches. Recuerda que el propio Sistema Operativo tiene caches de disco (contenido estatico). Soluciones como Squid o mod_proxy de apache ayudan. En ultima instancia que tu aplicación reimplemente (o reinvente la rueda) un cache.
3.- Si no puedes hacer estático o usar caches, vuelve a darle una pensada, algo esta mal.

Si usas el "ab" (apache benchmarks), veras que el contenido estatico corre mucho más rápido que el dinámico. Puedes ver incluso diferencias de 10 a 20 veces más rápido.

Si lo que generas tiene muchas más lecturas que escrituras, puedes hacer todo estático, menos un pequeño publicador. ¿Fastcgi? ¿mod_xxx?

Si hacer un publicador te resulta demasiado coñazo, puedes hacer algo dinamico y ponerlo tras un proxy. Debes ser muy cuidadoso con que el publicador informe de los tiempos de expiracion. Si no lo hace bien, tal vez puedas forzar al proxy a cachear, pero lo más probable es que esto te genere problemas. Si un usuario postea un mensaje y no lo ve, lo volvera a postear; hasta que el proxy refresque y vea que ha introducido todos.

Hay publicadores que tienen su propia cache. Otros incluso su propio servidor de base de datos. Yo prefiero las cosas que hacen solo una cosa, pero la hacen bien (caso raro el del apache que hace tantas cosas y tan bien). Si un publicador rellena correctamente las cabeceras http, y responde al metodo HEAD (no solo del GET y el POST viven los navegadores) correctamente, tendras un cache tan bueno como el que te de el mejor proxy inverso que seas capaz de configurar (ej: squid). no necesita gestionar una caché :-D

Espero que te sirva de algo, aunque si explicas de que va lo que va a correr en el servidor igual es más facil afinar.

Por cierto, si te compilas apache "a medida" puedes reducir la memoria ocupada por proceso (tener cargado el mod_dav y no usarlo es darse patadas en los 0_O). Y viendo que andas limitado de memoria, esto puede serte muy util.

Es una auténtica pesadilla porque la BIOS de esos aparatos está desdoblada en 2:

Por un lado está en el chip flasheable de la placa madre, y por otro está en la partición "Compaq Diagnostics" en el disco duro.

Después de grabar esa "partición Compaq" (desde 2 Diskettes que te puedes descargar de Compaq), resulta que te cambia la geometría del disco y hay que usar fdisk de Linux para arreglar el fregao.

Además, esa BIOS dice ser de plug and play pero sólo lo es a medias para algunos productos.

Total, que es un verdadero desafío. Pero el placer de conseguir que un trasto infame funcione...sólo es para unos pocos.

Os animo para que os agreguéis al "club".

hombre... cada uno tiene su punto de vista... pero limitar los visitantes solo a los españoles, no me parece un método de optimizacion muy razonable. Y fuera de españa no solo hay alemanes ;)