Category Archives: Apache - Page 4

Instalar extensiones de FrontPage en Directadmin

Me da cierta vergüenza tener que publicar este artículo por las tecnologías de las que voy a hablar: FrontPage y Apache 1.3. Pero entenderán que son cosas que aún se usan y cada tanto nos vemos obligados a lidiar con ellas.

Las extensiones de FrontPage son básicamente una serie de scripts que corren del lado del servidor y que, como su nombre lo indica, extienden la funcionalidad del FrontPage. A pesar de ser un producto de Microsoft, es compatible con Apache.

El tema es que, al menos en Directadmin, solamente es compatible con Apache 1.3. Según entiendo, las extensiones en sí se pueden instalar con Apache 2.x, pero el Directadmin solamente las soporta cuando se usa la versión 1.3.

Ahora bien, esta instalación no vamos a poder realizarla con Custombuild, sino que tenemos que recurrir al más antiguo CustomApache. Entonces los pasos serían los siguientes:

Descargar e instalar CustomApache:

cd /usr/local/directadmin
mkdir customapache
cd customapache
wget http://files.directadmin.com/services/customapache/build
chmod 755 build
./build update

Lo más sencillo ahora sería ejecutar build all, que va a instalar el Apache y las extensiones:

./build all

Si por alguna razón no se quiere compilar e instalar todo, se puede compilar Apache con:

./build apache_mod_ssl

Y luego habría que instalar las extensiones:

./build mod_frontpage

Por último, y esto es muy importante, hace falta habilitar las extensiones para que Directadmin muestre el correspondiente menú. Para ello es necesario editar el archivo /usr/local/directadmin/conf/directadmin.conf y poner el parámetro frontpage_on en 1.

frontpage_on=1

Luego se reinicia el servicio del Directadmin y listo:

service directadmin restart

Reduciendo el tráfico usando cache en Apache

Todos sabemos que en servidores de alta concurrencia el tema del tráfico es crítico. Reducir la cantidad de requests (pedidos) HTTP que hacen los clientes de un sitio muy visitado resulta clave para optimizar el rendimiento de nuestro servidor. Cada pedido implica una cantidad de ancho de banda que se consume (el pedido que va y la respuesta que vuelve) y procesamiento del lado del servidor y del cliente. Si logramos reducir la cantidad de los requests vamos a estar aliviando tanto el ancho de banda como la carga del servidor, con lo cual, vamos a poder atender a mayor cantidad de clientes con los mismos recursos.

Apache Web Server

Apache Web Server

Hay muchos aspectos en el diseño de la arquitectura de una aplicación que deben ser tenidos en cuenta para reducir la cantidad de requests. No podemos cubrir todos aquí, pero uno fundamental es el cache. El cache es, por lo general, una reproducción estática de un conjunto de información dinámica. Es decir, un almacenamiento temporal de una información que puede cambiar, durante un período de tiempo en el que se supone que no ha de hacerlo.

Por ejemplo, si yo tengo un conjunto grande de datos sobre los ingresos de los miembros de una familia y debo mostrar informes realizados sobre esos datos, tendría que hacer toda una serie de cálculos que mes a mes irían dando resultados distintos. Si yo sé que a lo largo de un mes, los datos de orígen no van a cambiar, puedo hacer un cache (una copia de los resultados ya calculados) para mostrarlos durante todo ese mes y no volver a hacer los cálculos.

Hay varios tipos de cache, que se pueden implementar en distintos segmentos de la arquitectura de una aplicación. En este caso nos ocuparemos del cache que se hace en el cliente HTTP (el browser) para evitar hacer consultas innecesarias al servidor (el Apache), con los beneficios que mencionamos más arriba.

Cuando cualquiera de nosotros visita un sitio web con un browser común, éste último se ocupa de hacer un request HTTP al servidor pidiendo el contenido de la URL que solicitamos (por ejemplo, el contenido del archivo http://www.tail-f.com.ar/index.php). Ahora bien, cuando recibe el contenido del archivo, si es HTML, es muy probable que éste incluya referencias a toda otra serie de archivos (imágenes, archivos de CSS, archivos de JavaScript, etc.). Automáticamente, y en forma totalmente transparente para nosotros, el browser va a hacer los requests de esos archivos, para bajar las imágenes y archivos que necesite para mostrarnos la página web a la que nosotros queremos acceder. Pero ¿qué sucede?, muchos de estos archivos, especialmente las imágenes, lo más probable es que no cambien casi nunca. El logo de la empresa dueña del sitio seguirá siendo el mismo y si yo actualizo la página o voy de la home a la sección de contacto, el logo que aparece en el encabezado se estaría descargando muchas veces. La gente que definió el protocolo HTTP ya tenía en mente este tipo de situaciones, entonces definió una serie de directivas que se envían en los headers de los mensajes HTTP, a través de las cuales el servidor le puede indicar al cliente si debe guardar ese archivo y por cuánto tiempo. De esta manera, al visitar la home del sitio por primera vez, el servidor puede decirme “este logo va a permanecer igual por todo un mes, así que guardalo y no me lo vuelvas a pedir hasta entonces”, y si yo soy obediente, lo haré, y nos haré un favor a los dos. Porque la próxima vez que vea que un HTML de este sitio me indica que tengo que poner la imagen logo.jpg en algún lado, la buscaré en mi disco rígido en vez de pedírsela al servidor, pudiendo mostrarla mucho más rápido al visitante.

¿Cómo se configura esto en Apache?

Hay dos módulos de Apache que nos servirán en este punto:

El primero permite manipular los headers (cabeceras) de los requests y responses que envía Apache. El segundo sirve para control uno de esos headers en particular, que es justamente el llamado “Expires”, que define el tiempo de expiración del archivo que se está mandando en un response.

Por lo tanto, aplicando unas reglas con expresiones regulares y estos dos módulos, en el httpd.conf de Apache o en un .htaccess, podemos definir cómo será el tratamiento de distintos tipos de archivos.

Por una cuestión de simplicidad yo lo he probado con un .htaccess, pero usarlo en el httpd.conf resultaría más óptimo aún, porque el procesamiento del .htaccess de por sí le quita rendimiento a Apache.

A continuación, dejo un ejemplo de configuración de un .htaccess en el cual se define que los archivos multimedia (sonido y video) deberán ser cacheados por un año, las imágenes por una semana, los archivos estáticos más comunes (html, css, js) cada 2 horas y los archivos dinámicos (php, cgi, pl) no deberán tener cache.

# Turn on Expires and set default to 0
ExpiresActive On
ExpiresDefault A0

# Set up caching on media files for 1 year (forever?)
<FilesMatch "\.(flv|ico|pdf|avi|mov|ppt|doc|mp3|wmv|wav)$">
ExpiresDefault A29030400
Header append Cache-Control "public"
</FilesMatch>

# Set up caching on media files for 1 week
<FilesMatch "\.(gif|jpg|jpeg|png|swf)$">
ExpiresDefault A604800
Header append Cache-Control "public"
</FilesMatch>

# Set up 2 Hour caching on commonly updated files
<FilesMatch "\.(xml|txt|html|js|css)$">
ExpiresDefault A7200
Header append Cache-Control "proxy-revalidate"
</FilesMatch>

# Force no caching for dynamic files
<FilesMatch "\.(php|cgi|pl|htm)$">
ExpiresActive Off
Header set Cache-Control "private, no-cache, no-store, proxy-revalidate, no-transform"
Header set Pragma "no-cache"
</FilesMatch>

Fuente del código: AskApache.com