nf_conntrack: table full, dropping packet

NetworkingEsta semana me he encontrado con un servidor CentOS con varios mensajes de error como el que sigue, en su fichero de logs messages:

Mar 14 18:55:48 localhost kernel: nf_conntrack: table full, dropping packet.

Ya había visto antes este error, que se solucionaría de forma radical, reiniciando el server, pero por suerte un compañero ya había hecho algo de investigación sobre este mismo problema.

Para empezar, ¿a qué se refiere este problema? Aquí lo explican bastante bien. El Connection Tracking le permite al kernel mantener un seguimiento de todas las conexiones (o sesiones) abiertas con el servidor, y poder así relacionar los paquetes con su correspondiente conexión. Así, Connection Tracking puede entender que dos o más conexiones distintas están «relacionadas». Por ejemplo, cuando se abre una sesión FTP, primero se abre una conexión contra el puerto 21 para iniciar la sesión FTP, y después se abre otra conexión contra el 20 o contra un puerto aleatorio en función de como tengamos configurado el servidor FTP. En cualquier caso, el Connection Tracking se encargaría de marcar ambas conexiones como relacionadas (RELATED).

Continuar leyendo «nf_conntrack: table full, dropping packet»

Optimiza el rendimiento de tu web

A raíz de EventoSEO, he mirado de optimizar el rendimiento de alguna de mis webs. Agarráos que esta entrada será larga, porqué voy a explicar algunos pasos que he dado para optimizar mi sitio web:

  1. Instala (si no lo tienes ya) Firebug y Google PageSpeed para Firefox.
  2. Desde Firefox -> Herramientas -> Firebug, abre Firebug y sitúate sobre la pestaña «Page Speed».
  3. Abre una nueva pestaña y entra en la web que quieres analizar. Espera hasta que esté cargada completamente (verás el «Terminado» abajo a la izquierda en el navegador).
  4. Si no estás viendo la sección del Firebug, podrás verla pulsando sobre el icono de Firebug en la barra de tareas inferior de Firefox.
  5. Pulsa sobre la opción Analizar para obtener las recomendaciones a seguir para optimizar tu web, como por ejemplo, optimizar la compresión de las imágenes (Google Page Speed ya te ofrece las imagenes problemáticas listas para descargar en su versión optimizada), comprimir la web con Gzip o minimizar el código CSS o HTML inútil.
  6. Siguiendo las recomendaciones obtenidas, se puede llegar a optimizar el rendimiento de nuestra web consiguiendo así una mejor indexación en el índice de Google, además de una mejor experiencia para el usuario.

Además de la optimización de las imágenes, dejo aquí algunas alertas que he recibido, junto a su solución:

Minimize CSS

Esto es tan fácil como descargar el archivo css que propone Google, el cual elimina espacios y saltos de línea innecesarios, y reemplazárlo por el original.

Minimize HTML

Igual que en el caso anterior, bastará con descargar el archivo propuesto por Google, el cual elimina espacios y saltos de línea innecesarios. Pero atención, si eres de los que programa con tabulaciones, para dejar un código límpio y fácil de leer, esto te lo va a destrozar. Guárdate una copia en local.

Minimize Redirects

Con mensajes de error como los siguientes:

Remove the following redirect chain if possible:

Este problema venía dado por que a estas imágenes se les hacía referencia desde el código como 02.jpg, mientras que su nombre era 02.JPG. Símplemente cambiando la extensión .JPG por .jpg se ha solucionado.

Opciones de servidor

Finalmente, tambien he obtenido alertas bastante más difíciles de solucionar. Concretamente, alertas correspondientes a opciones a cambiar o a habilitar en mi servidor web, que resulta ser un hosting compartido sobre el que no tengo acceso directo.

A pesar de eso, he conseguido obtener detalles sobre mi servidor web subiendo un fichero llamado info.php con una única línea de código:

<? phpinfo() ?>

Consultando esta web desde el navegador (http://www.misitio.com/info.php) se obtienen los detalles del hosting. Con esto y con la creación (o modificación) de un fichero .htaccess en la raíz de mi sitio web (con los detalles correspondientes) se puede llegar a solucionar algunos problemas, como los siguientes:

Leverage Browser Caching

Bastará con añadir líneas que controlen la caché para algunos elementos de nuestra web, en nuestro archivo .htaccess

Para ello, podremos usar el siguiente código

####### LeverageBrowserCaching #####
# 1 WEEK
<FilesMatch «\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$»>
Header set Cache-Control «max-age=604800, public»
</FilesMatch>

# 2 DAYS
<FilesMatch «\.(xml|txt)$»>
Header set Cache-Control «max-age=172800, public, must-revalidate»
</FilesMatch>

# 2 HOURS
<FilesMatch «\.(html|htm)$»>
Header set Cache-Control «max-age=7200, must-revalidate»
</FilesMatch>

#######################

La fuente de información es esta.

Enable Compression

Podremos habilitar la compresión tanto para las hojas de estilo como para los archivos html. Sin embargo, esta opción necesita que el servidor tenga instalado el módulo para comprimir, como el mod_gzip.

En mi caso he tenido que pedirle a mi hosting su instalación. Aún estoy esperando respuesta, y de momento, continúo con esta advertencia en el Page Speed Score.

Serve static content from a cookieless domain

Aquí, PageSpeed me pide «Serve the following static resources from a domain that doesn’t set cookies:» indicándo algunas imágenes, así como la hoja de estilos.

Para ello, en un segundo dominio diferente al dominio original, he creado varios sub-dominios (esto en realidad no haría falta, pero por temas de optimización, he creado un sub-dominio cada 3 imágenes, para poderlas cargar en paralelo. Si no sabes de qué hablo mírate este post).

Por cierto, no sé por qué extraña razón, mi hosting tarda unas 3 horas en crear un sub-dominio.

En resumen, si PageSpeed nos comenta usar un dominio libre de cookies, es porqué detecta que el actual no lo es. Según leo aquí, para usar un dominio libre de cookies, deberás usar un dominio que siempre haya estado libre de cookies (nunca haya requerido ningún tipo de inicio de sesión, ni logueos, ni Google Analytics activado para este dominio).

Una vez hecho esto, he redireccionado todos los sub-dominios a un directorio en mi servidor, donde tengo todas las imágenes.

Posteriormente, en el código fuente, he llamado a las imágenes, pero en lugar de usar «imagenes/1.JPG» he usado «http://1.sub-dominio.segundodominio.com/1.JPG», para llamarlas usando los nuevos sub-dominios.

Otros detalles

Aún me quedan algunos detalles que pulir, como por ejemplo que cada página use su propio archivo de hojas de estilo, con los estilos que use esa página. El problema de usar una única hoja de estilos global, es que la mayoría de páginas no usarán ni la mitad de los estilos definidos en el css común.

Entiendo, que lo ideal sería crear una hoja de estilos con los estilos comunes en todas las páginas, y a partir de ahí, una hoja de estilos personalizada para cada página.

También me queda pendiente habilitar la compresión en el servidor (me temo que tendré que pelearme con mi hosting), y finalmente también pulir el CSS, que todo y que es totalmente válido (validado con el validador de w3cschools) se me queja de que no es todo lo eficiente que debería ser.

De todas maneras, ya estoy en 93 – 95 sobre 100, en cuanto a puntuación de Google Page Speed, y la verdad, se nota.