Obtener un listado de links rotos
Hoy leí en Diario Linux un interesante post que explica cómo obtener un listado de los links rotos de una web. Lo ejecuté en NetStorming y, luego de un par de horas de ejecución, encontró 11 links rotos que tendré que arreglar.
La forma de hacer esto es muy sencilla y se realiza mediante el comando wget como se ve a continuación:
wget --spider --no-parent -r -o log.txt http://www.netstorming.com.ar
El listado de los links rotos aparecerá al final del archivo log.txt.
APC: acelerador de PHP en CentOS
Estos días que estuve intentando mejorar el rendimiento del servidor decidí probar APC por ser un acelerador open source que está cobrando mucha importancia en la actualidad.
Mi intención en este post es compartir en las siguientes líneas cómo realizar la instalación en CentOS en unos pocos y sencillos pasos.
- APC lo instalaremos con PECL, por lo que necesitaremos dicho comando. El mismo se provee en el paquete php-pear.
- Se necesitará también phpize, que se incluye en el paquete php-devel.
- Adicionalmente, es necesario contar con el comando apxs que es parte de httpd-devel.
Para ello:
yum install php-pear php-devel httpd-devel
Una vez instalados los paquetes anteriores entonces sí puede instalarse apc vía pecl:
pecl install apc
Con apc instalado, el último paso es agregar la extensión a PHP.
echo "extension=apc.so" > /etc/php.d/apc.ini
Listo, finalmente se reinicia el servidor web Apache para que se tomen los cambios:
service httpd restart
Se puede verificar que el módulo se cargue correctamente escribiendo el famoso archivo test.php en algún lugar accesible vía web con el siguiente contenido:
<?php phpinfo() ?>
Invocamos dicho archivo desde el navegador y debería aparecer una sección dedicada a APC. Obviamente, luego de chequearlo es importante borrar el archivo debido a que provee información muy sensible del servidor.
Instalación de Lighttpd
Debido a que recientemente instalé lighttpd en mi servidor con CentOS decidí compartir la documentación de lo realizado con los lectores de NetStorming, dado que quizá pueda servirles. Es muy probable que varias de las cosas que dejo debajo se puedan hacer de una manera mejor debido a que reitero que recién estoy conociendo el producto. En tal caso será bienvenido cualquier comentario y/o consejo.
Entorno
Básicamente en el servidor tengo tres blogs con WordPress y diferentes dominios. Además, cada dominio tiene en algunos casos más de un nombre que lo identifica. Los dominios en cuestión son:
- netstorming.com.ar
- mikroways.net
- leandroditommaso.com.ar
Instalación de Lighttpd
Para instalar Lighttpd en CentOS es necesario tener habilitado el repositorio de RPMForge. Luego, simplemente se invoca a yum con los siguientes paquetes:
yum install lighttpd.i386 lighttpd-fastcgi.i386 lighttpd-mod_mysql_vhost.i386
Configuración
El archivo de configuración del servidor se encuentra en /etc/lighttpd/lighttpd.conf. Al principio de dicho archivo se definen los módulos a habilitar. Por defecto no viene casi ningún módulo habilitado por lo cuál debemos elegir los que utilizaremos. En mi caso:
server.modules = (
"mod_rewrite",
"mod_redirect",
"mod_access",
"mod_fastcgi",
"mod_simple_vhost",
"mod_cgi",
"mod_accesslog" )
En la configuración anterior se puede ver que se habilitaron los módulos de FastCGI y CGI. Luego, es necesario descomentar las siguientes líneas para que funcione.
fastcgi.server = ( ".php" =>
( "localhost" =>
(
"socket" => "/var/run/lighttpd/php-fastcgi.socket",
"bin-path" => "/usr/bin/php-cgi"
)
)
)
cgi.assign = ( ".pl" => "/usr/bin/perl",
".cgi" => "/usr/bin/perl" )
Ahora bien, para utilizar FastCGI con PHP es necesario crear el directorio donde se ubicará el socket junto con el archivo del mismo y luego darle los permisos al usuario que ejecuta lighttpd, que por defecto es lighttpd.
mkdir /var/run/lighttpd touch /var/run/lighttpd/php-fastcgi.socket-0 chown -R lighttpd:lighttpd /var/run/lighttpd
Luego es necesario definir los diferentes hosts virtuales. En mi caso:
$HTTP["host"] == "^www\.mikroways\.(net|com.ar|com)" {
server.document-root = "/var/www/mikroways/"
server.name = "www.mikroways.net"
}
$HTTP["host"] =~ "(leandroditommaso.com.ar|www.leandroditommaso.com.ar|ditommaso.com.ar|www.ditommaso.com.ar)" {
server.document-root = "/var/www/leandroditommaso/"
server.name = "leandroditommaso.com.ar"
}
$HTTP["host"] =~ "www.netstorming.com.ar" {
server.document-root = "/var/www/netstorming/"
server.name = "www.netstorming.com.ar"
}
Como WordPress ejecutado con Apache se vale de un archivo .htaccess para realizar algunas reescrituras necesarias para su funcionamiento que no funcionan con Lighttpd es necesario incluir dichas reescrituras en el lenguaje del servidor web. Las cláusulas que dejo debajo pueden ponerse una única vez de forma general o múltiples veces dentro de la configuración de cada host virtual.
url.rewrite = ( "^/(wp-.+).*/?" => "$0", "^/(sitemap.xml)" => "$0", "^/(xmlrpc.php)" => "$0", "^/(.+)/?$" => "/index.php/$1" )
Prueba y retoques finales
Para verificar el funcionamiento de lo realizado es necesario reiniciar el servicio:
service lighttpd restart
Luego, configurarlo para que arranque al inicio:
chkconfig --level 35 lighttpd on
Conclusión
Con lo hecho en este post ya se puede tener un servidor con Lighttpd funcionando con soporte para PHP, hosts virtuales y el módulo de reescritura. Y todo con muy pocos y sencillos pasos. En un próximo post, luego de investigar un poco más, trataré el tema de las redirecciones, mejorando algunas cosas de la configuración anterior.
Migrado a Lighttpd
Siempre trabajé con Apache y es el servidor web que más conozco. No obstante, en esta oportunidad y debido a los repetidos problemas de rendimiento que estaba experimentando en el servidor decidí migrar a lighttpd y me llevé una muy grata sorpresa en cuanto a la facilidad de configuración y la buena documentación existente en Internet. En sólo cuestión de 2 horas realicé la migración completa (no es sólo NetStorming lo único que tengo hosteado en este servidor) sin tener ningún conocimiento previo de lighttpd.
Debajo dejo unos benchmark que realicé para probar el rendimiento. Lógicamente son resultados aproximados pero sirven para dar una idea aproximada.
El primer caso es con Apache, realizando un total de 1000 requerimientos con 20 requerimientos concurrentes.
scarlet:~ leandro$ ab -c 20 -n 1000 http://www.netstorming.com.ar/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking www.netstorming.com.ar (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests
Server Software: Apache/2.2.3
Server Hostname: www.netstorming.com.ar
Server Port: 80
Document Path: /
Document Length: 66636 bytes
Concurrency Level: 20
Time taken for tests: 130.533 seconds
Complete requests: 1000
Failed requests: 5
(Connect: 0, Receive: 0, Length: 5, Exceptions: 0)
Write errors: 0
Total transferred: 66835655 bytes
HTML transferred: 66546077 bytes
Requests per second: 7.66 [#/sec] (mean)
Time per request: 2610.652 [ms] (mean)
Time per request: 130.533 [ms] (mean, across all concurrent requests)
Transfer rate: 500.02 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 12 269 684.2 31 6355
Processing: 107 2145 4548.3 789 46182
Waiting: 14 442 2047.6 38 33040
Total: 120 2414 4734.8 1016 46251
Percentage of the requests served within a certain time (ms)
50% 1016
66% 1736
75% 2334
80% 3034
90% 4816
95% 9787
98% 15225
99% 23594
100% 46251 (longest request)
En el segundo caso hice la prueba contra lighttpd, en las mismas condiciones que en la prueba anterior.
scarlet:~ leandro$ ab -c 20 -n 1000 http://www.netstorming.com.ar/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking www.netstorming.com.ar (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests
Server Software: lighttpd/1.4.22
Server Hostname: www.netstorming.com.ar
Server Port: 80
Document Path: /
Document Length: 66636 bytes
Concurrency Level: 20
Time taken for tests: 44.020 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 66944310 bytes
HTML transferred: 66638613 bytes
Requests per second: 22.72 [#/sec] (mean)
Time per request: 880.390 [ms] (mean)
Time per request: 44.020 [ms] (mean, across all concurrent requests)
Transfer rate: 1485.14 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 11 98 234.6 53 4021
Processing: 99 753 1052.0 452 10156
Waiting: 14 150 426.5 61 3222
Total: 125 851 1087.1 518 11139
Percentage of the requests served within a certain time (ms)
50% 518
66% 685
75% 833
80% 1014
90% 1481
95% 3488
98% 4159
99% 4679
100% 11139 (longest request)
En el tercer caso hice la prueba contra el mismo lighttpd pero aumenté de 20 a 30 la cantidad de requerimientos concurrentes.
scarlet:~ leandro$ ab -c 30 -n 1000 http://www.netstorming.com.ar/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking www.netstorming.com.ar (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests
Server Software: lighttpd/1.4.22
Server Hostname: www.netstorming.com.ar
Server Port: 80
Document Path: /
Document Length: 66636 bytes
Concurrency Level: 30
Time taken for tests: 44.389 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 67034669 bytes
HTML transferred: 66727905 bytes
Requests per second: 22.53 [#/sec] (mean)
Time per request: 1331.679 [ms] (mean)
Time per request: 44.389 [ms] (mean, across all concurrent requests)
Transfer rate: 1474.76 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 11 125 331.9 51 4048
Processing: 114 1078 2221.6 445 33317
Waiting: 14 225 767.8 57 9178
Total: 135 1203 2255.5 535 33372
Percentage of the requests served within a certain time (ms)
50% 535
66% 795
75% 1223
80% 1452
90% 2829
95% 4159
98% 5553
99% 10425
100% 33372 (longest request)
Se puede ver que lighttpd responde mucho más rápido que Apache incluso con 30 requerimientos concurrentes. Eso sin realizar ningún tipo de tunning en lighttpd, con la instalación por defecto. Veré en los próximos días si el consumo de memoria del servidor es menor y si deja de quedarse fuera de servicio. Por lo pronto estoy conforme con los resultados obtenidos.
Utilizar Apache como frontend a JBoss
Por medio del módulo mod_jk es posible utilizar Apache como el servidor público y que sea éste el encargado de redirigir las peticiones al servidor JBoss correspondiente. Las ventajas de este enfoque son varias:
- Es Apache quien maneja las conexiones públicas, lo que nos da todas las garantías que el software provee.
- Permite que los accesos a los servicios de JBoss sean por medio del puerto 80, en lugar del 8080 que utiliza por defecto JBoss. Esto es bueno en muchos casos donde los usuarios no pueden acceder a puertos diferentes del 80.
- Es posible habilitar SSL en Apache y encriptar de esa manera las conexiones al servidor JBoss.
- La forma más trivial de hacer balanceo de carga entre servidores JBoss es utilizando Apache.
La manera de configurar dicho módulo en Ubuntu es bastante sencilla, sólo basta con seguir los pasos que se listan a continuación.
aptitude install libapache2-mod-jk
Editar el archivo de vhost que redigirá a JBoss:
JkMount /OpenKM default JkMount /OpenKM/* default
En el archivo anterior, JkMount recibe dos parámetros: el primero es la URL que se desea redirigir y el segundo es el “worker” al que se lo redireccionará. Luego es necesario indicar dónde contactar dicho “worker”. Para ello, en un nuevo archivo:
# Define 1 real worker named ajp13 worker.list=default # Set properties for worker named ajp13 to use ajp13 protocol, # and run on port 8009 worker.default.type=ajp13 worker.default.host=localhost worker.default.port=8009
Luego, como último paso, es necesario indicarle a Apache dónde buscar la configuración del worker. Para ello, editar el archivo /etc/apache2/conf.d/jk.conf:
JkWorkersFile "/etc/apache2/workers.properties" JkLogFile "/var/log/apache2/mod_jk.log" JkLogLevel info JkMount /OpenKM/ ajp13 JkMount /OpenKM/* ajp13
Finalmente basta con reiniciar el Apache y todo ya se podrá acceder al servicio por medio de la URL especificada.
